Re: [Python-Dev] New poll about a macro for safe reference replacing

[Serhiy Storchaka]

On 22.12.15 18:36, Meador Inge wrote:

On Tue, Dec 22, 2015 at 3:58 AM, Serhiy Storchaka mailto:storch...@gmail.com>> wrote:

On 21.12.15 23:57, Steve Dower wrote:

Was Py_MOVEREF (or MOVE_REF) ever suggested?


This would be nice name. The macro moves the ownership. But I think
it's too late. Otherwise we'll never finish the bikeshedding.


FWIW, I like this name the best.  It is increasingly popular for
languages to talk about moving ownership (e.g. move semantics in C++,
Rust, etc...).


Oh, I'm confused. Should I make a new poll? With new voters Py_MOVEREF 
can get more votes than Py_SETREF.



___
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] New poll about a macro for safe reference replacing

[Chris Angelico]

On Thu, Dec 24, 2015 at 1:50 AM, Serhiy Storchaka  wrote:
> Oh, I'm confused. Should I make a new poll? With new voters Py_MOVEREF can
> get more votes than Py_SETREF.

I suggest cutting off the bikeshedding. Both of these options have
reasonable support. Pick either and run with it, and don't worry about
another vote.

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] New poll about a macro for safe reference replacing

[Serhiy Storchaka]

On 23.12.15 16:52, Chris Angelico wrote:

On Thu, Dec 24, 2015 at 1:50 AM, Serhiy Storchaka  wrote:

Oh, I'm confused. Should I make a new poll? With new voters Py_MOVEREF can
get more votes than Py_SETREF.


I suggest cutting off the bikeshedding. Both of these options have
reasonable support. Pick either and run with it, and don't worry about
another vote.


This would be a voluntarism.


___
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] New poll about a macro for safe reference replacing

[Nick Coghlan]

On 24 December 2015 at 00:50, Serhiy Storchaka  wrote:
> On 22.12.15 18:36, Meador Inge wrote:
>>
>> On Tue, Dec 22, 2015 at 3:58 AM, Serhiy Storchaka > > wrote:
>>
>> On 21.12.15 23:57, Steve Dower wrote:
>>
>> Was Py_MOVEREF (or MOVE_REF) ever suggested?
>>
>>
>> This would be nice name. The macro moves the ownership. But I think
>> it's too late. Otherwise we'll never finish the bikeshedding.
>>
>>
>> FWIW, I like this name the best.  It is increasingly popular for
>> languages to talk about moving ownership (e.g. move semantics in C++,
>> Rust, etc...).
>
>
> Oh, I'm confused. Should I make a new poll? With new voters Py_MOVEREF can
> get more votes than Py_SETREF.

Within the Python context, the analogy from setattr and setitem at the
Python level to Py_SETREF at the C level is pretty solid, so it likely
makes sense to run with that as "good enough".

In regards to Py_MOVEREF, while other languages are starting to pay
more attention to "MOVE" semantics, we haven't really done so in
Python yet (moving references in Rust isn't the same thing we're
talking about here - this is just normal runtime reference counting).

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] New poll about a macro for safe reference replacing

[Meador Inge]

On Wed, Dec 23, 2015 at 9:08 AM, Nick Coghlan  wrote:


> Within the Python context, the analogy from setattr and setitem at the
> Python level to Py_SETREF at the C level is pretty solid, so it likely
> makes sense to run with that as "good enough".
>
> In regards to Py_MOVEREF, while other languages are starting to pay
> more attention to "MOVE" semantics, we haven't really done so in
> Python yet (moving references in Rust isn't the same thing we're
> talking about here - this is just normal runtime reference counting).
>

Oh.  I misunderstood the intent of the macro before
(from "The macro moves the ownership").  You are right.
Move semantics in C++ and Rust is different.
In this case the ownership is not being moved in the same
sense as though languages.

I withdraw my vote for Py_MOVEREF.  Py_SETREF is fine.

-- Meador
___
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] Typo in PEP-0423

[Chris Jerdonek]

On Tue, Dec 22, 2015 at 4:35 PM, Benjamin Peterson  wrote:
> We've played around with robots.txt, but it's still useful for old docs
> to be indexed (e.g., for removed features), which just need to figure
> out how to get them deprecation in results. I wonder if  ref="canonical"> in the old docs would help.

Yes, this is probably the correct approach (though it's rel="canonical"):

https://support.google.com/webmasters/answer/139066?hl=en

It's always been an inconvenience when Google displays the docs for
different, old versions (3.2, 3.3, etc) -- seemingly at random, and
sometimes instead of the newest version.  Fortunately, this seems to
be improving over time.

By using rel="canonical", you would have control over this and can
signal to Google to display only the newest, stable version of a given
doc.  This would probably have other positive benefits like
consolidating the "search juice" onto one page, so it's no longer
spread thinly across multiple versions.  There would still be a
question of how you want to handle 2 versus 3.

--Chris


>
> On Sat, Dec 19, 2015, at 11:02, A.M. Kuchling wrote:
>> On Sat, Dec 19, 2015 at 08:55:26PM +1000, Nick Coghlan wrote:
>> > Even once the new docs are in place, getting them to the top of search
>> > of results ahead of archived material that may be years out of date is
>> > likely to still be a challenge - for example, even considering just
>> > the legacy distutils docs, the "3.1" and "2" docs appear ...
>>
>> We probably need to update https://docs.python.org/robots.txt, which
>> currently contains:
>>
>> # Prevent development and old documentation from showing up in search
>> results.
>> User-agent: *
>> # Disallow: /dev
>> Disallow: /release
>>
>> The intent was to allow the latest version of the docs to be crawled.
>> Unfortunately, with the current hierarchy we'd have to disallow each
>> version, e.g.
>>
>> Disallow: /2.6/*
>> Disallow: /3.0/*
>> Disallow: /3.1/*
>>
>> And we'd need to update it for each new major release.
>>
>> --amk
>> ___
>> 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/benjamin%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/chris.jerdonek%40gmail.com
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] New poll about a macro for safe reference replacing

[Stephen J. Turnbull]

Serhiy Storchaka writes:

 > This would be a voluntarism.

You did due diligence, took the poll, and got additional information
as well.  It is *very* clear to me at least that you are paying full
attention to the poll.  Yes, the bikeshedding should end but I think
you should do as you think best in light of all the information.  That
is, don't worry about the *exact numerical* results of the poll if they
conflict with your best judgment.

He-who-does-the-work-makes-the-decisions-ly y'rs,

___
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