Re: [Python-Dev] version numbers mismatched in google search results.

2014-01-31 Thread Vincent Davis 
On Fri, Jan 31, 2014 at 5:41 AM, Rick Boyce  wrote:

> 28.3. builtins — Built-in objects — Python 3.3.3 documentation ->
> https://docs.python.org/3/library/builtins.html
>

​I can't get the  https  link
to work. Does python.org support
https?
it should :-)​


Vincent Davis
720-301-3003
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] version numbers mismatched in google search results.

2014-01-31 Thread Vincent Davis 
As I understand it,
http://docs.python.org/library
redirects
to  
http://docs.python.org/2/library
so
that old links, blog posts. that exist in the world and originally
referenced python 2 will still work as they pointed to
http://docs.python.org/library
(no version number)
* Is this correct?

At some point 
http://docs.python.org/library
should
stop working.
I would consider adding release numbers, i.e
http://docs.python.org/3.4/library

All this makes me think it would be cool to have a DIFF button on document
pages that would show a diff between version number. i.e. when I read a
blog post about X and I follow the link in the post to doc version a.b I
can see a quick diff to see how it (docs) compare to version c.d I am using.

I think http://docs.python.org
should
be a landing page not forwarded to current version docs. Maybe something
like http://www.python.org/doc/versions/ although I think that should be
here http://docs.python.org/versions/


Vincent Davis
720-301-3003


On Fri, Jan 31, 2014 at 5:41 AM, Rick Boyce  wrote:

> I get caught out a lot by the titles Google is showing for pages quite
> often too, but as far I can tell they are not related to the /dev docs.
>
> If I Google "python builtins" the top 3 results, for me, are as follows:
>
> 2. Built-in Functions — Python v2.7.6 documentation ->
> http://docs.python.org/library/functions.html
> 28.3. builtins — Built-in objects — Python 3.3.3 documentation ->
> https://docs.python.org/3/library/builtins.html
> Built-in objects - Python 3.3.3 documentation ->
> http://docs.python.org/library/__builtin__.html
>
> The top two are fine, but the last one is a Python 2 docs page but Google
> shows the title as being for 3.3. This seems to be really common when
> googling for python docs.
>
> At least the design of the two versions is different enough that you spot
> it immediately, but it happens often enough to be confusing all the same!
>
> Rick
>
>
> On 25 January 2014 13:47, Vincent Davis  wrote:
>
>> When I do a google search the version numbers are mismatched with the
>> linked page (or redirected).
>> For example search for "python counter" I get the following results.
>> (see attachment)
>> It seems like the website is redirecting incorrectly.
>>
>>
>>1. collections - Python 3.3.3 
>> documentation
>>1. links to http://docs.python.org/library/collections.html
>>   2. redirects to http://docs.python.org/2/library/collections.html
>>   3. Which is python 2.7.6
>>2. itertools - Python 3.3.3 
>> documentation
>>1. links to http://docs.python.org/library/itertools.html
>>   2. redirects to http://docs.python.org/2/library/itertools.html
>>   3. Which is again 2.7.6
>>3. 8.3. collections — Container datatypes - Python 3.3.3 
>> documentation
>>1. This one seems correct, 3.40b2
>>   2. links to http://docs.python.org/dev/library/collections
>>
>> The link to addresses are not really true, they look more like:
>>
>> https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&ved=0CCcQFjAA&url=http%3A%2F%2Fdocs.python.org%2Flibrary%2Fcollections.html&ei=k7vjUqPrHM_jsAS-m4G4Cw&usg=AFQjCNFTyb_RHzPdorBGavEIR_ekNn_AFA&sig2=yW6S02oUEfioUot11lTAlQ&bvm=bv.59930103,d.cWc
>>
>> Vincent Davis
>>
>>
>> ___
>> Python-Dev mailing list
>> [email protected]
>> https://mail.python.org/mailman/listinfo/python-dev
>> Unsubscribe:
>> https://mail.python.org/mailman/options/python-dev/rickboyce%40gmail.com
>>
>>
>
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] version numbers mismatched in google search results.

2014-01-31 Thread Rick Boyce 
I get caught out a lot by the titles Google is showing for pages quite
often too, but as far I can tell they are not related to the /dev docs.

If I Google "python builtins" the top 3 results, for me, are as follows:

2. Built-in Functions -- Python v2.7.6 documentation ->
http://docs.python.org/library/functions.html
28.3. builtins -- Built-in objects -- Python 3.3.3 documentation ->
https://docs.python.org/3/library/builtins.html
Built-in objects - Python 3.3.3 documentation ->
http://docs.python.org/library/__builtin__.html

The top two are fine, but the last one is a Python 2 docs page but Google
shows the title as being for 3.3. This seems to be really common when
googling for python docs.

At least the design of the two versions is different enough that you spot
it immediately, but it happens often enough to be confusing all the same!

Rick


On 25 January 2014 13:47, Vincent Davis  wrote:

> When I do a google search the version numbers are mismatched with the
> linked page (or redirected).
> For example search for "python counter" I get the following results. (see
> attachment)
> It seems like the website is redirecting incorrectly.
>
>
>1. collections - Python 3.3.3 
> documentation
>1. links to http://docs.python.org/library/collections.html
>   2. redirects to http://docs.python.org/2/library/collections.html
>   3. Which is python 2.7.6
>2. itertools - Python 3.3.3 
> documentation
>1. links to http://docs.python.org/library/itertools.html
>   2. redirects to http://docs.python.org/2/library/itertools.html
>   3. Which is again 2.7.6
>3. 8.3. collections -- Container datatypes - Python 3.3.3 
> documentation
>1. This one seems correct, 3.40b2
>   2. links to http://docs.python.org/dev/library/collections
>
> The link to addresses are not really true, they look more like:
>
> https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&ved=0CCcQFjAA&url=http%3A%2F%2Fdocs.python.org%2Flibrary%2Fcollections.html&ei=k7vjUqPrHM_jsAS-m4G4Cw&usg=AFQjCNFTyb_RHzPdorBGavEIR_ekNn_AFA&sig2=yW6S02oUEfioUot11lTAlQ&bvm=bv.59930103,d.cWc
>
> Vincent Davis
>
>
> ___
> Python-Dev mailing list
> [email protected]
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/rickboyce%40gmail.com
>
>
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] version numbers mismatched in google search results.

2014-01-31 Thread Rick Boyce 
>
> On 31 January 2014 14:23, Vincent Davis  wrote:
>
>>
>> On Fri, Jan 31, 2014 at 5:41 AM, Rick Boyce  wrote:
>>
>>> 28.3. builtins -- Built-in objects -- Python 3.3.3 documentation ->
>>> https://docs.python.org/3/library/builtins.html
>>
>>
>> I can't get the  https  link
>> to work. Does python.org support  
>> https?
>> it should :-)
>>
>
My mistake - I must have added the extra s when I de-googleized the URL.
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Summary of Python tracker Issues

2014-01-31 Thread Python tracker 

ACTIVITY SUMMARY (2014-01-24 - 2014-01-31)
Python tracker at http://bugs.python.org/

To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.

Issues counts and deltas:
  open4484 ( +9)
  closed 27748 (+70)
  total  32232 (+79)

Open issues with patches: 2036 


Issues opened (58)
==

#3158: Doctest fails to find doctests in extension modules
http://bugs.python.org/issue3158  reopened by zach.ware

#20383: Add a keyword-only spec argument to types.ModuleType
http://bugs.python.org/issue20383  opened by brett.cannon

#20384: os.open() exception doesn't contain file name on Windows
http://bugs.python.org/issue20384  opened by serhiy.storchaka

#20386: socket.SocketType enum overwrites import of _socket.SocketType
http://bugs.python.org/issue20386  opened by giampaolo.rodola

#20387: tokenize/untokenize roundtrip fails with tabs
http://bugs.python.org/issue20387  opened by jason.coombs

#20389: clarify meaning of xbar and mu in pvariance/variance of statis
http://bugs.python.org/issue20389  opened by jtaylor

#20391: windows python launcher should support explicit 64-bit version
http://bugs.python.org/issue20391  opened by theller

#20392: Inconsistency with uppercase file extensions in MimeTypes.gues
http://bugs.python.org/issue20392  opened by rodrigo.parra

#20393: Docs: mark deprecated items in the TOC
http://bugs.python.org/issue20393  opened by zearin

#20394: Coverity complains on audioop
http://bugs.python.org/issue20394  opened by serhiy.storchaka

#20396: Argument Clinic: Touch source file if any output file changed
http://bugs.python.org/issue20396  opened by larry

#20397: distutils --record option does not validate existance of byte-
http://bugs.python.org/issue20397  opened by marcusva

#20399: Comparison of memoryview
http://bugs.python.org/issue20399  opened by fin.swimmer

#20400: Add create_read_pipe_protocol/create_write_pipe_protocol to as
http://bugs.python.org/issue20400  opened by haypo

#20402: List comprehensions should be noted in for loop documentation
http://bugs.python.org/issue20402  opened by robla

#20403: Idle options dialog: add help
http://bugs.python.org/issue20403  opened by terry.reedy

#20404: Delayed exception using non-text encodings with TextIOWrapper
http://bugs.python.org/issue20404  opened by ncoghlan

#20405: Add io.BinaryTransformWrapper and a "transform" parameter to o
http://bugs.python.org/issue20405  opened by ncoghlan

#20406: Use application icon for IDLE
http://bugs.python.org/issue20406  opened by serhiy.storchaka

#20408: memoryview() constructor documentation error
http://bugs.python.org/issue20408  opened by larry

#20410: Argument Clinic: add 'self' return converter
http://bugs.python.org/issue20410  opened by zach.ware

#20412: Enum and IntEnum classes are not defined in the documentation
http://bugs.python.org/issue20412  opened by ethan.furman

#20413: Errors in documentation of standard codec error handlers
http://bugs.python.org/issue20413  opened by RalfM

#20414: Python 3.4 has two Overlapped types
http://bugs.python.org/issue20414  opened by haypo

#20415: Could method "isinstance" take a list as parameter?
http://bugs.python.org/issue20415  opened by Chen.ZHANG

#20416: Marshal: special case int and float, don't use references
http://bugs.python.org/issue20416  opened by haypo

#20417: ensurepip should not be installed with --without-ensurepip
http://bugs.python.org/issue20417  opened by Arfrever

#20420: BufferedIncrementalEncoder violates IncrementalEncoder interfa
http://bugs.python.org/issue20420  opened by serhiy.storchaka

#20421: expose SSL socket protocol version
http://bugs.python.org/issue20421  opened by pitrou

#20423: io.StringIO newline param has wrong default
http://bugs.python.org/issue20423  opened by couplewavylines

#20426: Compiling a regex with re.DEBUG should force a recompile
http://bugs.python.org/issue20426  opened by leewz

#20428: _Py_open does not work with O_CREAT
http://bugs.python.org/issue20428  opened by alexandre.vassalotti

#20429: 3.3.4rc1 install deleted Windows taskbar icons
http://bugs.python.org/issue20429  opened by terry.reedy

#20430: Make argparse.SUPPRESS work as an argument "dest"
http://bugs.python.org/issue20430  opened by jzwinck

#20431: Should posix functions that accept fd also accept objects with
http://bugs.python.org/issue20431  opened by larry

#20432: Argument Clinic: when cloning functions with path_t, path_t re
http://bugs.python.org/issue20432  opened by larry

#20433: add aliasedname() and namedaliases() methods to unicodedata mo
http://bugs.python.org/issue20433  opened by jamadagni

#20434: Process crashes if not enough memory to import module
http://bugs.python.org/issue20434  opened by qualab

#20435: Discrepancy between io.StringIO and _pyio.StringIO with univer
http://bugs.python.org/issue20435  opened by serhiy.storchaka

#20437: Use Py_CLEAR to safe clear attributes
http://bugs.python.org/issue20437  open

Re: [Python-Dev] Negative times behaviour in itertools.repeat for Python maintenance releases (2.7, 3.3 and maybe 3.4)

2014-01-31 Thread Larry Hastings 

On 01/28/2014 09:18 PM, Ethan Furman wrote:

On 01/28/2014 06:50 PM, Larry Hastings wrote:
I think the "times behaves differently when passed by name versus 
passed by position" behavior falls exactly into this

category, and its advice on how to handle it is sound.


I don't agree with this.  This is a bug.  Somebody going through (for 
example) a code review and making minor changes so the code is more 
readable shouldn't have to be afraid that [inserting | removing] the 
keyword in the function call is going to *drastically* [1] change the 
behavior.  I understand the need for a cycle of deprecation [2], but 
not fixing it in 3.5 is folly.


It's a bug.  But it's also a longstanding bug, having been a part of 
Python since 2.7.


Python is the language that cares about backwards-compatibility--bugs 
and all.  If your code runs on version X.Y, it should run without 
modification on version X.(Y+Z) where Z is a positive integer.


Therefore it would be inappropriate to remove the "times=-1 when passed 
by keyword repeats indefinitely" behavior without at /least/ a full 
deprecation cycle.  Personally I'd prefer to leave the behavior in, 
undocumented and deprecated, until Python 4.0.



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

Re: [Python-Dev] Negative times behaviour in itertools.repeat for Python maintenance releases (2.7, 3.3 and maybe 3.4)

2014-01-31 Thread Steven D'Aprano 
On Fri, Jan 31, 2014 at 07:23:52PM -0800, Larry Hastings wrote:

> Python is the language that cares about backwards-compatibility--bugs 
> and all.  If your code runs on version X.Y, it should run without 
> modification on version X.(Y+Z) where Z is a positive integer.
> 
> Therefore it would be inappropriate to remove the "times=-1 when passed 
> by keyword repeats indefinitely" behavior without at /least/ a full 
> deprecation cycle.

That is a reasonable and responsible position to take.


> Personally I'd prefer to leave the behavior in, 
> undocumented and deprecated, until Python 4.0.

It's one thing to avoid removing things which do no harm, 
but this is a bug which does harm. Anyone who refactors 

repeat(x, count)

to 

repeat(x, times=count)

(or vice versa) is in for a nasty surprise if count ever becomes 
negative.

If anyone out there relies on this bug, they can get the same behaviour 
easily, and end up with better code:


# Before.
repeat(x, times=-1)  # Magic to make x repeat forever.

# After.
repeat(x)  # Non-magic fully documented way of getting x to repeat forever.


Given support for times=None at the same time, then it's easy to support 
the use-case of "sometimes I want an infinite repeat, sometimes I don't, 
but I won't know until runtime":


# Before.
values = (100, -1)  # Repeat 100 times, or forever.
repeat(x, times=random.choice(values))

# After.
values = (100, None)  # Repeat 100 times, or forever.
repeat(x, times=random.choice(values))


I can see that delaying for a depreciation cycle is the responsible 
thing to do. I don't think delaying fixing this until some hypothetical 
distant Python 4000 is a good idea.



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

Re: [Python-Dev] Negative times behaviour in itertools.repeat for Python maintenance releases (2.7, 3.3 and maybe 3.4)

2014-01-31 Thread Ethan Furman 

On 01/31/2014 07:23 PM, Larry Hastings wrote:

On 01/28/2014 09:18 PM, Ethan Furman wrote:

On 01/28/2014 06:50 PM, Larry Hastings wrote:

I think the "times behaves differently when passed by name versus passed by 
position" behavior falls exactly into this
category, and its advice on how to handle it is sound.


I don't agree with this.  This is a bug.  Somebody going through (for example) 
a code review and making minor changes
so the code is more readable shouldn't have to be afraid that [inserting | 
removing] the keyword in the function call
is going to *drastically* [1] change the behavior.  I understand the need for a 
cycle of deprecation [2], but not
fixing it in 3.5 is folly.


It's a bug.  But it's also a longstanding bug, having been a part of Python 
since 2.7.

Python is the language that cares about backwards-compatibility--bugs and all.  
If your code runs on version X.Y, it
should run without modification on version X.(Y+Z) where Z is a positive 
integer.


So we only fix bugs that don't work at all?  By which I mean, if the 
interpreter doesn't crash, we don't fix it?



Therefore it would be inappropriate to remove the "times=-1 when passed by keyword 
repeats indefinitely" behavior
without at /least/ a full deprecation cycle.  Personally I'd prefer to leave 
the behavior in, undocumented and
deprecated, until Python 4.0.


Well, at least we are agreed on a deprecation cycle.  :)

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