Re: [Python-Dev] unicode_string future, str -> basestring, fix or feature

2014-03-02 Thread Serhiy Storchaka 

03.03.14 02:02, Terry Reedy написав(ла):

On 3/2/2014 4:23 PM, Serhiy Storchaka wrote:

02.03.14 22:01, Terry Reedy написав(ла):

Is this a programmer error for passing unicode instead of string, or a
library error for not accepting unicode?
Is changing 'isinstance(x, str)' in the library (with whatever other
changes are needed) a bugfix to be pushed or a prohibited API expansion?


Patches which add support for unicode strings were accepted for one
issues (e.g. http://bugs.python.org/issue19099) and rejected for other
issues (e.g. http://bugs.python.org/issue20014 and
http://bugs.python.org/issue20015). Some issues (e.g.
http://bugs.python.org/issue18695) hang in undefined state.


If Antoine and Guido don't reverse themselves, those could perhaps be
re-opened. It strikes me as borderline, depending interpretation of
'string'. I am not surprised there have been different resolutions.


I believe that in all cases when valid values are ASCII-only strings 
(format specifiers for array, struct, memoryview, etc), we can accept 
both str and unicode. Especially when they are likely literals. But when 
valid value can be non-ASCII (e.g. file names), it is a different case, 
because it requires additional and may be totally different code.



___
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] unicode_string future, str -> basestring, fix or feature

2014-03-02 Thread Guido van Rossum 
AFACT, in that message Victor was only talking about allowing Unicode
filenames.

Making everything polymorphic is clearly pulling on the thread that will
unravel the entire sweater.

But... The start of this thread was about changing a few occurrences of
isinstance(..., str) to use basestring, and that's a different matter. The
Python 2 Unicode design calls for mixing of Unicode and 8-bit strings as
long as the latter contain 7-bit ASCII -- the code in turtle violates that
design by insisting on an 8-bit string. The underlying Tkinter module
handles Unicode strings just fine (and not just 7-bit ASCII).

As far as lib2to3 goes, using basestring instead of str actually
disambiguates things -- with str it can't tell for sure whether text or
binary was meant, but with basestring it's a safe bet that the intention
was text.

Finally, in most places Python 2.7 *does* handle Unicode filenames just
fine.


On Sun, Mar 2, 2014 at 6:26 PM, Stephen J. Turnbull wrote:

> Terry Reedy writes:
>  > On 3/2/2014 4:23 PM, Serhiy Storchaka wrote:
>
>  > > Patches which add support for unicode strings were accepted for one
>  > > issues (e.g. http://bugs.python.org/issue19099) and rejected for
> other
>  > > issues (e.g. http://bugs.python.org/issue20014 and
>  > > http://bugs.python.org/issue20015). Some issues (e.g.
>  > > http://bugs.python.org/issue18695) hang in undefined state.
>  >
>  > If Antoine and Guido don't reverse themselves, those could perhaps be
>  > re-opened. It strikes me as borderline, depending interpretation of
>  > 'string'. I am not surprised there have been different resolutions.
>
> I agree with Victor in http://bugs.python.org/issue18695#msg208857:
> there's no "bug".  It is just that in the design of 2.x 'str' is not
> Unicode, and the "fix" is Python 3.  This may be an area where 2to3
> could give more help.
>
> As Victor points out in that message, the issue-by-issue approach to
> this inconsistency is just whack-a-mole.
>
> I would worry not only about the whack-a-mole aspect where 'unicode'
> objects leak into contexts where they're not supported, but also that
> this could confuse tools like 2to3.
>
> I agree that usage of the word "string" is all too often ambiguous in
> the documentation, but that doesn't justify a wholesale overhaul of
> the Python 2.7 API to make everything polymorphic.
>
> ___
> 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/archive%40mail-archive.com

Re: [Python-Dev] unicode_string future, str -> basestring, fix or feature

2014-03-02 Thread Stephen J. Turnbull 
Terry Reedy writes:
 > On 3/2/2014 4:23 PM, Serhiy Storchaka wrote:

 > > Patches which add support for unicode strings were accepted for one
 > > issues (e.g. http://bugs.python.org/issue19099) and rejected for other
 > > issues (e.g. http://bugs.python.org/issue20014 and
 > > http://bugs.python.org/issue20015). Some issues (e.g.
 > > http://bugs.python.org/issue18695) hang in undefined state.
 > 
 > If Antoine and Guido don't reverse themselves, those could perhaps be 
 > re-opened. It strikes me as borderline, depending interpretation of 
 > 'string'. I am not surprised there have been different resolutions.

I agree with Victor in http://bugs.python.org/issue18695#msg208857:
there's no "bug".  It is just that in the design of 2.x 'str' is not
Unicode, and the "fix" is Python 3.  This may be an area where 2to3
could give more help.

As Victor points out in that message, the issue-by-issue approach to
this inconsistency is just whack-a-mole.

I would worry not only about the whack-a-mole aspect where 'unicode'
objects leak into contexts where they're not supported, but also that
this could confuse tools like 2to3.

I agree that usage of the word "string" is all too often ambiguous in
the documentation, but that doesn't justify a wholesale overhaul of
the Python 2.7 API to make everything polymorphic.

___
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] unicode_string future, str -> basestring, fix or feature

2014-03-02 Thread Nick Coghlan 
On 3 March 2014 10:02, Terry Reedy  wrote:
> On 3/2/2014 4:23 PM, Serhiy Storchaka wrote:
>>
>> 02.03.14 22:01, Terry Reedy написав(ла):
>>>
>>> Is this a programmer error for passing unicode instead of string, or a
>>> library error for not accepting unicode?
>>> Is changing 'isinstance(x, str)' in the library (with whatever other
>>> changes are needed) a bugfix to be pushed or a prohibited API expansion?
>>
>>
>> Patches which add support for unicode strings were accepted for one
>> issues (e.g. http://bugs.python.org/issue19099) and rejected for other
>> issues (e.g. http://bugs.python.org/issue20014 and
>> http://bugs.python.org/issue20015). Some issues (e.g.
>> http://bugs.python.org/issue18695) hang in undefined state.
>
>
> If Antoine and Guido don't reverse themselves, those could perhaps be
> re-opened. It strikes me as borderline, depending interpretation of
> 'string'. I am not surprised there have been different resolutions.

It occurs to me that it would be good to have a "bug fix or feature?"
section in the developer guide to provide a more permanent record of
dicussions like this. That would also be the place to document tricks
like defining a private API to fix a bug in a maintenance release, and
then potentially making that new API public for the next feature
release if it's potentially useful to end users.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
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] unicode_string future, str -> basestring, fix or feature

2014-03-02 Thread Terry Reedy 

On 3/2/2014 4:23 PM, Serhiy Storchaka wrote:

02.03.14 22:01, Terry Reedy написав(ла):

Is this a programmer error for passing unicode instead of string, or a
library error for not accepting unicode?
Is changing 'isinstance(x, str)' in the library (with whatever other
changes are needed) a bugfix to be pushed or a prohibited API expansion?


Patches which add support for unicode strings were accepted for one
issues (e.g. http://bugs.python.org/issue19099) and rejected for other
issues (e.g. http://bugs.python.org/issue20014 and
http://bugs.python.org/issue20015). Some issues (e.g.
http://bugs.python.org/issue18695) hang in undefined state.


If Antoine and Guido don't reverse themselves, those could perhaps be 
re-opened. It strikes me as borderline, depending interpretation of 
'string'. I am not surprised there have been different resolutions.


--
Terry Jan Reedy


___
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] unicode_string future, str -> basestring, fix or feature

2014-03-02 Thread Berker Peksağ 
On Sun, Mar 2, 2014 at 11:23 PM, Serhiy Storchaka  wrote:
> Patches which add support for unicode strings were accepted for one issues
> (e.g. http://bugs.python.org/issue19099) and rejected for other issues (e.g.
> http://bugs.python.org/issue20014 and http://bugs.python.org/issue20015).

See also http://bugs.python.org/issue15843.

--Berker
___
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] unicode_string future, str -> basestring, fix or feature

2014-03-02 Thread Serhiy Storchaka 

02.03.14 22:01, Terry Reedy написав(ла):

Is this a programmer error for passing unicode instead of string, or a
library error for not accepting unicode?
Is changing 'isinstance(x, str)' in the library (with whatever other
changes are needed) a bugfix to be pushed or a prohibited API expansion?


Patches which add support for unicode strings were accepted for one 
issues (e.g. http://bugs.python.org/issue19099) and rejected for other 
issues (e.g. http://bugs.python.org/issue20014 and 
http://bugs.python.org/issue20015). Some issues (e.g. 
http://bugs.python.org/issue18695) hang in undefined state.


___
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] unicode_string future, str -> basestring, fix or feature

2014-03-02 Thread Terry Reedy 

On 3/2/2014 3:12 PM, Guido van Rossum wrote:

It looks to me like a defect in the library (*), and you are making a
reasonable argument that we should fix it in 2.7 to help people be more
prepared for the transition to Python 3.

(*) As Antoine points out, pretty much the only time where it's not a
good idea to switch from str to basestring is when the data is meant to
be binary -- but in this case it's clearly text (we can also tell from
what the same code looks like in Python 3 :-).


Thanks to both of you. 'bugfix' noted on the issue.


On Sun, Mar 2, 2014 at 12:01 PM, Terry Reedy mailto:tjre...@udel.edu>> wrote:

Suppose a 2.7 standard library function is documented as taking a
'string' argument, such as these examples from the turtle module.

pencolor(colorstring)
 Set pencolor to colorstring, which is a Tk color specification
string, such as "red", "yellow", or "#33cc8c".

turtle.shape(name=None)
 Parameters: name – a string which is a valid shapename

class turtle.Shape(type_, data)
 Parameters: type_ – one of the strings “polygon”, “image”,
“compound”

Suppose adding
from __future__ import unicode_literals
to a working program causes an exception, such as with turtle
http://bugs.python.org/__issue15618 
(Note: unicode_literals is not indexed.)

Is this a programmer error for passing unicode instead of string, or
a library error for not accepting unicode?
Is changing 'isinstance(x, str)' in the library (with whatever other
changes are needed) a bugfix to be pushed or a prohibited API expansion?


--
Terry Jan Reedy


___
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] Wave module support for floating point data

2014-03-02 Thread Serhiy Storchaka 

01.03.14 21:57, Sebastian Kraft написав(ла):

more than a year ago I have submitted a patch to enhance the Wave module
with read/write support for floating point data.

http://bugs.python.org/issue16525

Up till now this patch has not been applied nor did I get feedback if
anything needs to be enhanced or changed before it can be committed.
I have never been in contact with your development process and Python
core developers, so please tell me what I should improve...


I had assigned this issue to myself because I were going to solve it. 
There was too little time before features freeze, so the patch had been 
delayed until 3.5. As for the patch itself, there were many changes in 
the wave module last months, especially in the tests, so the patch can't 
be applied cleanly and should be rewritten.


The main problem is that this issue could not be resolved separately. 
First of all we should add support for floating point in the audioop 
module, we also need to add support for floating point in aifc and sunau 
modules. Need to design a new interface for audio modules.


___
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] unicode_string future, str -> basestring, fix or feature

2014-03-02 Thread Guido van Rossum 
It looks to me like a defect in the library (*), and you are making a
reasonable argument that we should fix it in 2.7 to help people be more
prepared for the transition to Python 3.

(*) As Antoine points out, pretty much the only time where it's not a good
idea to switch from str to basestring is when the data is meant to be
binary -- but in this case it's clearly text (we can also tell from what
the same code looks like in Python 3 :-).


On Sun, Mar 2, 2014 at 12:01 PM, Terry Reedy  wrote:

> Suppose a 2.7 standard library function is documented as taking a 'string'
> argument, such as these examples from the turtle module.
>
> pencolor(colorstring)
> Set pencolor to colorstring, which is a Tk color specification string,
> such as "red", "yellow", or "#33cc8c".
>
> turtle.shape(name=None)
> Parameters: name - a string which is a valid shapename
>
> class turtle.Shape(type_, data)
> Parameters: type_ - one of the strings "polygon", "image", "compound"
>
> Suppose adding
> from __future__ import unicode_literals
> to a working program causes an exception, such as with turtle
> http://bugs.python.org/issue15618
> (Note: unicode_literals is not indexed.)
>
> Is this a programmer error for passing unicode instead of string, or a
> library error for not accepting unicode?
> Is changing 'isinstance(x, str)' in the library (with whatever other
> changes are needed) a bugfix to be pushed or a prohibited API expansion?
>
> --
> Terry Jan Reedy
>
>
> ___
> 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/archive%40mail-archive.com

Re: [Python-Dev] unicode_string future, str -> basestring, fix or feature

2014-03-02 Thread Antoine Pitrou 
On Sun, 02 Mar 2014 15:01:01 -0500
Terry Reedy  wrote:
> Suppose a 2.7 standard library function is documented as taking a 
> 'string' argument, such as these examples from the turtle module.
> 
> pencolor(colorstring)
>  Set pencolor to colorstring, which is a Tk color specification 
> string, such as "red", "yellow", or "#33cc8c".
> 
> turtle.shape(name=None)
>  Parameters:  name – a string which is a valid shapename
> 
> class turtle.Shape(type_, data)
>  Parameters:  type_ – one of the strings “polygon”, “image”, 
> “compound”
> 
> Suppose adding
> from __future__ import unicode_literals
> to a working program causes an exception, such as with turtle
> http://bugs.python.org/issue15618
> (Note: unicode_literals is not indexed.)
> 
> Is this a programmer error for passing unicode instead of string, or a 
> library error for not accepting unicode?

In most cases I would say it's a library error.
The only exception is when the argument is clearly meant as a byte
string rather than a text string, such as when writing to a binary file
or a socket.

Regards

Antoine.


___
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

[Python-Dev] unicode_string future, str -> basestring, fix or feature

2014-03-02 Thread Terry Reedy 
Suppose a 2.7 standard library function is documented as taking a 
'string' argument, such as these examples from the turtle module.


pencolor(colorstring)
Set pencolor to colorstring, which is a Tk color specification 
string, such as "red", "yellow", or "#33cc8c".


turtle.shape(name=None)
Parameters: name – a string which is a valid shapename

class turtle.Shape(type_, data)
Parameters: type_ – one of the strings “polygon”, “image”, “compound”

Suppose adding
from __future__ import unicode_literals
to a working program causes an exception, such as with turtle
http://bugs.python.org/issue15618
(Note: unicode_literals is not indexed.)

Is this a programmer error for passing unicode instead of string, or a 
library error for not accepting unicode?
Is changing 'isinstance(x, str)' in the library (with whatever other 
changes are needed) a bugfix to be pushed or a prohibited API expansion?


--
Terry Jan Reedy


___
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] Removing doc from pythonhosted.org

2014-03-02 Thread Brett Cannon 
Best place for PyPI-related things is distutils-...@python.org. But for bug
reports related to PyPI, file them at
https://bitbucket.org/pypa/pypi/issues(it's actually linked off of
PyPI).


On Sat, Mar 1, 2014 at 1:30 PM, Giampaolo Rodola' wrote:

> I'm not sure whether this is the right mailing list where to post this.
> However, it seems the pypi UI currently provides a way to upload doc at
> the bottom of the page
> https://pypi.python.org/pypi?%3Aaction=pkg_edit&name=PROJECT_NAME but
> there's currently no way to remove it:
>
> https://bitbucket.org/pypa/pypi/issue/24/allow-deleting-project-documentation-from
> http://sourceforge.net/p/pypi/support-requests/294/
> https://github.com/litl/rauth/issues/81
>  The only workaround as of
> http://stackoverflow.com/questions/6521931/how-to-delete-documentation-from-pypiappears
>  to be uploading a new .zip file with a redirect.
>
> --
> Giampaolo - http://grodola.blogspot.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/brett%40python.org
>
>
___
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] Wave module support for floating point data

2014-03-02 Thread Antoine Pitrou 
On Sat, 01 Mar 2014 18:04:09 -0500
Terry Reedy  wrote:
> >>
> >> Please subscribe to core-mentorship list and post your question there.
> >
> > I don't understand this response. You seem to be assuming that
> > Sebastian is asking for guidance,
> 
> I am reading what he posted, which ended with "please tell me what I 
> should improve...".
> 
> This sort of question-request is routinely posted, in much the same 
> words, on core-mentorship, and routinely gets a response there.

I'm sure people who answer questions on core-mentorship also hang out
on python-dev, so I don't understand why it wouldn't get a response
*here*.

Regardless, the main problem with stale patches like Sebastian's is that
there isn't a core developer interested in reviewing them (or with the
required time to do so). Asking those people to post on core-mentorship
is a distraction: it won't make core developers magically more
available.

Regards

Antoine.


___
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] Wave module support for floating point data

2014-03-02 Thread Sebastian Kraft 

Am 01.03.2014 21:25, schrieb Antoine Pitrou:

On Sat, 01 Mar 2014 15:08:00 -0500
Terry Reedy  wrote:

On 3/1/2014 2:57 PM, Sebastian Kraft wrote:

Hi everybody,

more than a year ago I have submitted a patch to enhance the Wave module
with read/write support for floating point data.

http://bugs.python.org/issue16525

Up till now this patch has not been applied nor did I get feedback if
anything needs to be enhanced or changed before it can be committed.
I have never been in contact with your development process and Python
core developers, so please tell me what I should improve...


Please subscribe to core-mentorship list and post your question there.


I don't understand this response. You seem to be assuming that



It seems there is some confusion about how to handle this... Anyway I 
looked at the patch again and after the recent changes towards version 
3.4 the patch cannot be applied anymore. Taking into account that there 
was no interest in this area for the last years, I will not take the 
time to rework the patch. Anyway please consider to commit the new 
documentation patch I have uploaded to the issue.


http://bugs.python.org/issue16525

It is really necessary to clarify the suppoprted sample formats in the 
documentation.


Sebastian
___
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] Wave module support for floating point data

2014-03-02 Thread Tim Golden 

On 02/03/2014 10:25, Xavier de Gaye wrote:

The core-mentorship current archive is only available to the list
members as stated at the core-mentorship web site at
http://pythonmentors.com/.  Curious to know why.


The thinking behind c-m is to lower the entry bar for contribution. To 
that end, people can ask questions which might, to the more 
knowledgeable, appear naive. ("You don't know what Mercurial is?" 
"You've never used make?") If the archives were public then 
less-experienced questioners might shrink from exposing their ignorance 
and would ultimately not engage with Python development.


Another "rule" is that you should not quote c-m posts literally outside 
the c-m list. You can restate the question in general terms to, eg, get 
input from python-dev or python-committers. Advice *from* the committers 
on the list can be quoted elsewhere.


Note that the archives are open to all subscribers, and subscription is 
open to anyone. So it's not particularly secret, just a low barrier to 
remind people to respect the possible inexperience of posters.


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] Wave module support for floating point data

2014-03-02 Thread Xavier de Gaye 

On 03/02/2014 12:04 AM, Terry Reedy wrote:
> On 3/1/2014 3:25 PM, Antoine Pitrou wrote:
>> On Sat, 01 Mar 2014 15:08:00 -0500
>> Terry Reedy wrote:
>>> On 3/1/2014 2:57 PM, Sebastian Kraft wrote:
 Hi everybody,

 more than a year ago I have submitted a patch to enhance the Wave module
 with read/write support for floating point data.

 http://bugs.python.org/issue16525

 Up till now this patch has not been applied nor did I get feedback if
 anything needs to be enhanced or changed before it can be committed.
 I have never been in contact with your development process and Python
 core developers, so please tell me what I should improve...
>>>
>>> Please subscribe to core-mentorship list and post your question there.
>>
>> I don't understand this response. You seem to be assuming that
>> Sebastian is asking for guidance,
>
> I am reading what he posted, which ended with "please tell me what I should 
improve...".
>
> This sort of question-request is routinely posted, in much the same words, on 
core-mentorship, and routinely gets a response there.


The core-mentorship current archive is only available to the list members as 
stated at the core-mentorship web site at http://pythonmentors.com/.  Curious 
to know why.

Xavier
___
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] "Five reviews to get yours reviewed"?

2014-03-02 Thread Chris Angelico 
On Sun, Mar 2, 2014 at 7:48 PM, Terry Reedy  wrote:
> On 3/2/2014 1:51 AM, Chris Angelico wrote:
>>
>> On Sun, Mar 2, 2014 at 4:07 PM, Terry Reedy  wrote:
>>>
>>> On 3/1/2014 7:11 PM, Chris Angelico wrote:

 I have a couple of patches outstanding, notably issue 20249 [2], which
 is a small change, has a patch, and has no activity or nosying since
 its creation.
>>>
>>>
>>> And the other?
>>
>>
>> http://bugs.python.org/issue19494 has a patch that I uploaded, but
>> it's more accurately someone else's patch and I just made a slight
>> tweak to it.
>
>
> The line numbers in your patch do not match the line numbers in the 3.4
> file.  Did you prepare against 3.3?
>

Hmm. I definitely made sure it worked on 3.4, but IIRC the patch was
manually fudged from the 2.7 patch, so possibly I didn't get
everything perfect. But it does apply without errors:

rosuav@sikorsky:~/cpython$ hg impor aaa.patch
applying aaa.patch

(Yeah, I'm not imaginative with temporary file names. So sue me. :)

ChrisA
___
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] "Five reviews to get yours reviewed"?

2014-03-02 Thread Terry Reedy 

On 3/2/2014 1:51 AM, Chris Angelico wrote:

On Sun, Mar 2, 2014 at 4:07 PM, Terry Reedy  wrote:

On 3/1/2014 7:11 PM, Chris Angelico wrote:

I have a couple of patches outstanding, notably issue 20249 [2], which
is a small change, has a patch, and has no activity or nosying since
its creation.


And the other?


http://bugs.python.org/issue19494 has a patch that I uploaded, but
it's more accurately someone else's patch and I just made a slight
tweak to it.


The line numbers in your patch do not match the line numbers in the 3.4 
file.  Did you prepare against 3.3?


The base issue here is a policy question about accommodating violations 
of the standard. The main maintainer of the urllib.requests module is 
Senthil. I would not decide the policy question.



http://bugs.python.org/issue20729 is an issue that I opened, and
there's a patch at the issue, but I didn't write the patch.


I think Serhiy's patch is 'conservative', so I could look at it and see 
if I agree that it is the right minimal change.



Technically, neither really counts,


Martin's offer was to review a patch that one wanted reviewed, not 
necessarily one that one wrote.


--
Terry Jan Reedy

___
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