Re: [Python-Dev] [PATCH] unicode subtypes broken in latest py3k? debug builds

[sppook]

Sent from my Windows Phone___
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] PEP 463: Exception-catching expressions

[Chris Angelico]

On Fri, Feb 28, 2014 at 6:38 PM, Glenn Linderman  wrote:
> Whereas the current PEP syntax has ambiguity regarding how to interpret
> a-expr except except-list-b: b-expr except except-list-c: c-expr (does the
> 2nd except apply to a-expr or b-expr?), without parentheses, and, as far as
> I am concerned, even with the parentheses, this syntax makes it very clear
> that each of the Exception-lists apply to a-expr.

Fair enough. It's a bit hard to talk about multiple except
expressions, though, as they're a problem unless formally supported -
and they're almost never needed. Really, all you need to do is say
"never abut except-expressions without parentheses" (which the current
proposal and the "parens around the exception bit only" proposal both
enforce), and then there's no problem. I expect that normal use of
this won't include any form of chaining. Yes, it can - like any
feature - be used abnormally, but at some point it's better to just
drop it out as a statement.

> Key advantage to others may be that because the : is within the () [and the
> leading ( is quite nearby, making it obvious], it is less likely to be
> considered a statement boundary, and more easily explained as a special type
> of list syntax... not _really_ a list, because it is really code to be
> executed somewhat sequentially rather than data, and lists don't have : ...
> and not _really_ a dict constant, which does have :, because the Exception
> is not _really_ a key, but the syntax can draw on analogies with the dict
> constant syntax which will help people remember it, and even sort of
> understand that there is a pair-wise relationship between the Exception-list
> and the expression after the :, without repeating the except over and over.

See the confusing terminology we have here? It might be called a
"list" of except-expressions, but the brackets are round, and a list's
are square. It's kinda like dict syntax, only again, the other sort of
bracket, and it's wrong to try to construct a dict; it'd be too
tempting to conflate this with some of the other current proposals for
lazily-evaluated expressions (aka "simpler syntax for lambda" or other
terms). This is, fundamentally, a multi-part expression on par with
"and" and "or": first, evaluate the primary expression; then, if an
exception is raised, evaluate the exception list and see if it
matches; then, if it matches, squash the exception and evaluate the
default expression. You can't turn that into a dict, partly because
you'd need to sort out lazy evaluation, and partly because a dict is
unordered - if this is expanded to support multiple except clauses,
they have to be processed in order. (You might, for instance, catch
ZeroDivisionError, and then Exception, with different handling. It'd
be VERY confusing for them to be processed in the wrong order,
particularly if it happens unpredictably.)

Are there any other expressions that allow parens around a part of the
expression, without the stuff inside them becoming a completely
separate sub-expression?

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] Poll: Py_REPLACE/Py_ASSIGN/etc

[Larry Hastings]

On 02/26/2014 11:13 PM, Georg Brandl wrote:

Am 26.02.2014 17:09, schrieb Ryan Gonzalez:

I like Py_DECREF_REPLACE. It gives the impression that it decrefs the original
and replaces it.

Agreed, most other suggestions are not really explicit enough.


+1 from me too.  When I saw Py_SETREF I thought, oh, it sets the thing 
and increfs it.


FWIW this vote is just on the name.  I haven't stared at the whole 
Py_REPLACE idea enough to have an opinion about whether or not to use 
it.  But if we use it I'm +1 on Py_DECREF_REPLACE.



//arry/
___
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] PEP 463: Exception-catching expressions

[Glenn Linderman]

On 2/28/2014 12:41 AM, Chris Angelico wrote:

On Fri, Feb 28, 2014 at 6:38 PM, Glenn Linderman  wrote:

Whereas the current PEP syntax has ambiguity regarding how to interpret
a-expr except except-list-b: b-expr except except-list-c: c-expr (does the
2nd except apply to a-expr or b-expr?), without parentheses, and, as far as
I am concerned, even with the parentheses, this syntax makes it very clear
that each of the Exception-lists apply to a-expr.

Fair enough. It's a bit hard to talk about multiple except
expressions, though, as they're a problem unless formally supported -
and they're almost never needed. Really, all you need to do is say
"never abut except-expressions without parentheses" (which the current
proposal and the "parens around the exception bit only" proposal both
enforce), and then there's no problem. I expect that normal use of
this won't include any form of chaining. Yes, it can - like any
feature - be used abnormally, but at some point it's better to just
drop it out as a statement.


Key advantage to others may be that because the : is within the () [and the
leading ( is quite nearby, making it obvious], it is less likely to be
considered a statement boundary, and more easily explained as a special type
of list syntax... not _really_ a list, because it is really code to be
executed somewhat sequentially rather than data, and lists don't have : ...
and not _really_ a dict constant, which does have :, because the Exception
is not _really_ a key, but the syntax can draw on analogies with the dict
constant syntax which will help people remember it, and even sort of
understand that there is a pair-wise relationship between the Exception-list
and the expression after the :, without repeating the except over and over.

See the confusing terminology we have here? It might be called a
"list" of except-expressions, but the brackets are round, and a list's
are square. It's kinda like dict syntax, only again, the other sort of
bracket, and it's wrong to try to construct a dict; it'd be too
tempting to conflate this with some of the other current proposals for
lazily-evaluated expressions (aka "simpler syntax for lambda" or other
terms). This is, fundamentally, a multi-part expression on par with
"and" and "or": first, evaluate the primary expression; then, if an
exception is raised, evaluate the exception list and see if it
matches; then, if it matches, squash the exception and evaluate the
default expression. You can't turn that into a dict, partly because
you'd need to sort out lazy evaluation, and partly because a dict is
unordered - if this is expanded to support multiple except clauses,
they have to be processed in order. (You might, for instance, catch
ZeroDivisionError, and then Exception, with different handling. It'd
be VERY confusing for them to be processed in the wrong order,
particularly if it happens unpredictably.)


That's why I kept saying "not _really_" :)  It isn't a list, but it has 
an order requirement; it isn't a dict, but it has pairs; and finally, it 
isn't data, but code.  But nonetheless the analogies are somewhat useful.



Are there any other expressions that allow parens around a part of the
expression, without the stuff inside them becoming a completely
separate sub-expression?


Sure. Function invocation.  You can claim (and it is accurate) that the 
stuff inside is somewhat independent of the actual function called, but 
the syntax is  function-name open-paren parameter-list close-paren, and 
the stuff in the parens would be a tuple if it were purely data, except 
not quite a tuple because some items are pairs (name and value), but it 
winds up being neither a tuple, nor a list, nor a dict, but instead a 
complex structure related to code execution :)  Actually, this sounds 
quite similar to


value = expr except (
Exception1: default1,
Exception2: default2,
Exception3: default3,
   )

except that to get the pairing aspect of some parameters for a function call, 
you use = instead of :, and instead of a named function it has an expression 
and a keyword.

Not being an expert parser generator, I don't know if the () could be 
made optional if there is only one exception-list, but that would also 
remove one of the benefits some folks might perceive with using this 
syntax, and would also make the analogy with function call syntax a 
little less comparable.


Glenn
___
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] Start writing inlines rather than macros?

[Kristján Valur Jónsson]

> -Original Message-
> From: Python-Dev [mailto:python-dev-
> bounces+kristjan=ccpgames@python.org] On Behalf Of Skip Montanaro
> Sent: 27. febrúar 2014 19:12
> To: python-dev Dev
> Subject: Re: [Python-Dev] Start writing inlines rather than macros?
> one question though. Suppose you encounter a compiler that
> doesn't understand the inline keyword, so you choose the static declaration
> as Kristján suggested. The resulting Python executable should be functionally
> correct, but if the optimizer doesn't happen to inline a given static function
> you might be stuck with some bad performance across-the-board (if it never
> inlines, or doesn't inline where we really need it to), or only under some
> circumstances (as a hypothetical example, inlining in dictobject.c, but not in
> ceval.c).
> Is there a configurable way to tell if a compiler will inline functions which 
> are
> declared static, and possibly under what conditions they might not? It might
> still be necessary to maintain macros for those platforms.

It would be horrible to have to maintain both macros and functions.
My suggestion would be to use functions for new code, and new use cases.
We would stick with Py_INCREF() , and continue using that in obvious cases, 
(such
as in the implementation of the new functions)
but at the same time introduce a Py_IncRef() function returning a new reference,
which can be used in new code where it is convenient.

The new macros under discussion, Py_INCREF_AND_REPLACE_WITH_GUSTO() and
all of them would then be redesigned in a more composable functional form.

This way, only new code would be compiled with different efficiency on different
platforms, thus avoiding introducing performance regressions.

K
___
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] PEP 463: Exception-catching expressions

[Thomas Wouters]

On Fri, Feb 28, 2014 at 1:30 AM, Glenn Linderman wrote:

>
> value = expr except (
> Exception1: default1,
> Exception2: default2,
> Exception3: default3,
>)
>
> except that to get the pairing aspect of some parameters for a function call, 
> you use = instead of :, and instead of a named function it has an expression 
> and a keyword.
>
> [ Cue people suggesting the use of '=' or '=>' or '->' instead of ':' ]


> Not being an expert parser generator, I don't know if the () could
> be made optional if there is only one exception-list, but that would
> also remove one of the benefits some folks might perceive with using
> this syntax, and would also make the analogy with function call
> syntax a little less comparable.
>
> I believe it's possible, but it's probably tricky: the parser has to
consider two or three cases:

1.  expr1 except expr2: expr4
2.  expr1 except (expr2: expr4)
3.  expr1 except (expr2, expr3): expr4
4.  expr1 except ((expr2, expr3): expr4)

(for simplicity I use 'expr' here, which is entirely the wrong thing to do
in terms of CPython's grammar: there's different types of expressions for
different situations. #2 and #4 are actually automatically derived from #1
and #3 by 'expr' including tuples and parenthesized expressions.) CPython's
parser is a LL(1) parser, which means it can look ahead 1 character to
choose between alternatives (and that's not going to change, Guido likes it
this way -- and so I do, personally :). Looking at #2 and #3 you can't tell
which alternative to use until you see the ':' or ',' after 'expr2', which
is too late. The only way to handle that, I think, is to include all
possible alternatives in the grammar for the 'except' statement,
duplicating logic and definitions from a lot of places. We already do this
kind of thing to deal with other potentially-ambiguous situations (to
handle dicts and sets and dict comprehensions and set comprehensions, for
example) but this would be even more duplication.

It would be easier if we weren't talking about '(' or any other token that
can be part of a normal expression ;-P

[ Cue people suggesting the use of 'expr1 except < expr2: expr4 >'... ]

-- 
Thomas Wouters 

Hi! I'm an email virus! Think twice before sending your email to help me
spread!
___
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] PEP 463: Exception-catching expressions

[Chris Angelico]

On Fri, Feb 28, 2014 at 8:30 PM, Glenn Linderman  wrote:
> > Are there any other expressions that allow parens around a part of the
> > expression, without the stuff inside them becoming a completely
> > separate sub-expression?
>
>
> Sure. Function invocation.  You can claim (and it is accurate) that the
> stuff inside is somewhat independent of the actual function called, but the
> syntax is  function-name open-paren parameter-list close-paren, and the
> stuff in the parens would be a tuple if it were purely data, except not
> quite a tuple because some items are pairs (name and value), but it winds up
> being neither a tuple, nor a list, nor a dict, but instead a complex
> structure related to code execution :)

Thanks, that's exactly the sort of example I was looking for :) For
some reason I mentally blanked and didn't think of that. My point is,
if you're going to look for parens around the bit after except, we
should look at styling and layout that follows how that's done.

As TW says:
> [ Cue people suggesting the use of '=' or '=>' or '->' instead of ':' ]

If this is to be laid out like a function call, '=' would indeed make
sense. But let's stick to the colon for now, so this is a mix of
dict-style and function-call-style.

expr except(Exception: default)

In a more function-call-style layout, that would be:

expr except(Exception=default)

Both of those look reasonable, and they're tying the parens to the
word "except" so it can't *actually* be a function call. Then it looks
like it should be laid out like this:

except(expr, Exception=default)

and it really *is* looking like a function call - and now it's hit the
uncanny valley [1], where it's close enough to be a problem (eg
because of lazy evaluation, or because "Exception" could be
"(AttributeError, KeyError)", which can't be a keyword argument). I
don't like this last form; does anyone else support it?

Removing the space after the word "except" makes me a lot less averse
to this form. Funny how stylistic choices can influence a structural
one! Here are a few more examples. How do other people feel about
them?

cond = args[1] except(IndexError: None)

pwd = os.getcwd() except(OSError: None)

e.widget = self._nametowidget(W) except(KeyError=W)

line = readline() except(StopIteration='')

_CONFIG_VARS['abiflags'] = sys.abiflags except(AttributeError: '')

def getNamedItem(self, name):
return self._attrs[name] except(KeyError: None)

g = grp.getgrnam(tarinfo.gname)[2] except(KeyError=tarinfo.gid)
u = pwd.getpwnam(tarinfo.uname)[2] except(KeyError=tarinfo.uid)

mode = f.mode except(AttributeError: 'rb')

return sys._getframe(1) except(AttributeError=None)

ips.append(ip.ip except(AttributeError: ip.network_address))

dirlist.append(_os.getcwd() except((AttributeError, OSError)=_os.curdir))

The last one is really critical here, I think. It's the only stdlib
example I could find that catches two different errors (IIRC). Here it
is with the colon:

dirlist.append(_os.getcwd() except((AttributeError, OSError): _os.curdir))

Thoughts?

ChrisA

[1] http://tvtropes.org/pmwiki/pmwiki.php/Main/UncannyValley
___
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] Poll: Py_REPLACE/Py_ASSIGN/etc

[Nick Coghlan]

On 28 Feb 2014 19:05, "Larry Hastings"  wrote:
>
> On 02/26/2014 11:13 PM, Georg Brandl wrote:
>>
>> Am 26.02.2014 17:09, schrieb Ryan Gonzalez:
>>>
>>> I like Py_DECREF_REPLACE. It gives the impression that it decrefs the
original
>>> and replaces it.
>>
>> Agreed, most other suggestions are not really explicit enough.
>
>
> +1 from me too.  When I saw Py_SETREF I thought, oh, it sets the thing
and increfs it.
>
> FWIW this vote is just on the name.  I haven't stared at the whole
Py_REPLACE idea enough to have an opinion about whether or not to use it.
But if we use it I'm +1 on Py_DECREF_REPLACE.

For additional context, the idea itself is necessary for the same reason
Py_CLEAR was added: to help ensure that an object's state is never pointing
at another object that is in the process of being deleted. The difference
is that Py_CLEAR only allows setting the pointer to NULL, while the point
of the new macro is to set it to an arbitrary existing point. There is no
implicit incref as that isn't needed for correctness (you can do the incref
before the pointer replacement, and often the reference count will already
be correct without an explicit incref anyway).

With the new macro in place, the existing Py_CLEAR(x) macro would be
equivalent to Py_SETREF(x, NULL).

Originally I was also concerned about the "how will people know there's no
implicit incref?", but I've since become satisfied with the fact that the
precedent set by the reference stealing SET_ITEM macros is strong enough to
justify the shorter name.

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

Re: [Python-Dev] PEP 463: Exception-catching expressions

[Nick Coghlan]

On 28 February 2014 21:46, Chris Angelico  wrote:
> On Fri, Feb 28, 2014 at 8:30 PM, Glenn Linderman  
> wrote:
>> > Are there any other expressions that allow parens around a part of the
>> > expression, without the stuff inside them becoming a completely
>> > separate sub-expression?
>>
>> Sure. Function invocation.  You can claim (and it is accurate) that the
>> stuff inside is somewhat independent of the actual function called, but the
>> syntax is  function-name open-paren parameter-list close-paren, and the
>> stuff in the parens would be a tuple if it were purely data, except not
>> quite a tuple because some items are pairs (name and value), but it winds up
>> being neither a tuple, nor a list, nor a dict, but instead a complex
>> structure related to code execution :)
>
> Thanks, that's exactly the sort of example I was looking for :) For
> some reason I mentally blanked and didn't think of that. My point is,
> if you're going to look for parens around the bit after except, we
> should look at styling and layout that follows how that's done.

Also generator expressions and most uses of yield or yield from as
embedded expressions. Parentheses are our general "this next bit may
not be following the normal syntax rules" utility, in addition to
being used to override the normal precedence rules (square brackets
and curly braces similarly denote regions where the parsing rules may
differ from the top level ones).

As far as the specific problem I'm attacking with this variant of the
proposal goes, one of the recurring reactions from different people
has been "but colons are used to introduce suites, not expressions".
This impression is not, in fact, correct, as the colon is already used
as a subexpression separator in four cases:

* dict display key:value pairs
* slice notation start:stop:step triples
* function parameter : annotation separation
* lambda expression arg list : return value separation

PEP 463 just adds a fifth such case, as an exception spec:result separator.

The preferred notation in the PEP most resembles the existing lambda
use case, with "except" instead of "lambda", an exception handling
spec instead of an argument list and an additional leading expression:

(expr except Exception: default)

Lots of people don't like the lambda notation though, so it isn't
necessarily a particularly compelling parallel to use. By contrast,
it's rare to hear any objections to the {key:value} dict display
syntax. Hence the proposed tweak to the syntax to define an "exception
handler expression" syntax that is analogous to a dict display rather
than a lambda expression:

expr except (Exception: default)

However, I have realised that there *is* a major downside to that
notation, which is that it lacks the connotations of lazy evaluation
associated with lambda expressions, whereas the default result of an
except expression won't be evaluated at all if the exception isn't
thrown.

So I think that on balance, I actually do prefer your current
proposal. That said, I do think this is a variant worth discussing
explicitly in the PEP, if only to remind people that there's
definitely precedent for using a colon to separate two subexpressions
inside a larger expression element - it's not *just* used to introduce
suites, even though that is by far the most *common* use case.

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] PEP 463: Exception-catching expressions

[Chris Angelico]

On Fri, Feb 28, 2014 at 11:51 PM, Nick Coghlan  wrote:
> So I think that on balance, I actually do prefer your current
> proposal. That said, I do think this is a variant worth discussing
> explicitly in the PEP, if only to remind people that there's
> definitely precedent for using a colon to separate two subexpressions
> inside a larger expression element - it's not *just* used to introduce
> suites, even though that is by far the most *common* use case.

I've added a bit more to the PEP about that.

https://github.com/Rosuav/ExceptExpr/commit/f32387

Does that explain it, do you think?

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] PEP 463: Exception-catching expressions

[Nick Coghlan]

On 28 February 2014 23:07, Chris Angelico  wrote:
> On Fri, Feb 28, 2014 at 11:51 PM, Nick Coghlan  wrote:
>> So I think that on balance, I actually do prefer your current
>> proposal. That said, I do think this is a variant worth discussing
>> explicitly in the PEP, if only to remind people that there's
>> definitely precedent for using a colon to separate two subexpressions
>> inside a larger expression element - it's not *just* used to introduce
>> suites, even though that is by far the most *common* use case.
>
> I've added a bit more to the PEP about that.
>
> https://github.com/Rosuav/ExceptExpr/commit/f32387
>
> Does that explain it, do you think?

Yeah, that works. You may also want to add a "common objections"
section to explicitly cover the "but colons introduce suites"
objection. That would provide a space to explicitly list all of the
current "not introducing a suite" use cases for the colon in Python's
syntax, since increasing that tally from four to five is less radical
than introducing the first non-suite related use case for the symbol.

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] PEP 463: Exception-catching expressions

[Chris Angelico]

On Fri, Feb 28, 2014 at 11:51 PM, Nick Coghlan  wrote:
>>> > Are there any other expressions that allow parens around a part of the
>>> > expression, without the stuff inside them becoming a completely
>>> > separate sub-expression?
>
> Also generator expressions and most uses of yield or yield from as
> embedded expressions. Parentheses are our general "this next bit may
> not be following the normal syntax rules" utility, in addition to
> being used to override the normal precedence rules (square brackets
> and curly braces similarly denote regions where the parsing rules may
> differ from the top level ones).

In those cases, the "stuff inside the parens" is the entire syntactic
structure of that sub-element, right? I was looking for something
where there's syntax inside and syntax outside the parens, where
what's in the parens isn't just an expression or tuple, so I could try
laying out an except expression to imitate that style. The function
call is excellent; removing one space from the layout did make the
expression look better, but as explained above, I still prefer the
current form. Would like to make the parens optional; maybe make them
mandatory if there are two except-expressions abutting, or something,
but I'd like to simplify the syntax for the common case. Otherwise,
current syntax is still my personal preferred.

Of course, we still have to convince Guido that this is a good idea at
all, syntax or no :)

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] PEP 463: Exception-catching expressions

[Chris Angelico]

On Sat, Mar 1, 2014 at 12:24 AM, Nick Coghlan  wrote:
> Yeah, that works. You may also want to add a "common objections"
> section to explicitly cover the "but colons introduce suites"
> objection. That would provide a space to explicitly list all of the
> current "not introducing a suite" use cases for the colon in Python's
> syntax, since increasing that tally from four to five is less radical
> than introducing the first non-suite related use case for the symbol.

https://github.com/Rosuav/ExceptExpr/commit/b770f9

Any other objections that should be listed?

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] Poll: Py_REPLACE/Py_ASSIGN/etc

[Kristján Valur Jónsson]

+1
Also, for the equivalence to hold there is no separate Py_XSETREF, the X 
behaviour is implied, which I favour.  Enough of this X-proliferation already!
But also see the discussion on inlines.  It would be great to make this an 
inline rather than a macro.
K

From: Python-Dev [mailto:python-dev-bounces+kristjan=ccpgames@python.org] 
On Behalf Of Nick Coghlan
Sent: 28. febrúar 2014 12:27
To: Larry Hastings
Cc: python-dev@python.org
Subject: Re: [Python-Dev] Poll: Py_REPLACE/Py_ASSIGN/etc

For additional context, the idea itself is necessary for the same reason 
Py_CLEAR was added: to help ensure that an object's state is never pointing at 
another object that is in the process of being deleted. The difference is that 
Py_CLEAR only allows setting the pointer to NULL, while the point of the new 
macro is to set it to an arbitrary existing point. There is no implicit incref 
as that isn't needed for correctness (you can do the incref before the pointer 
replacement, and often the reference count will already be correct without an 
explicit incref anyway).

With the new macro in place, the existing Py_CLEAR(x) macro would be equivalent 
to Py_SETREF(x, NULL).

Originally I was also concerned about the "how will people know there's no 
implicit incref?", but I've since become satisfied with the fact that the 
precedent set by the reference stealing SET_ITEM macros is strong enough to 
justify the shorter name.

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

Re: [Python-Dev] Poll: Py_REPLACE/Py_ASSIGN/etc

[Barry Warsaw]

On Feb 28, 2014, at 10:27 PM, Nick Coghlan wrote:

>With the new macro in place, the existing Py_CLEAR(x) macro would be
>equivalent to Py_SETREF(x, NULL).
>
>Originally I was also concerned about the "how will people know there's no
>implicit incref?", but I've since become satisfied with the fact that the
>precedent set by the reference stealing SET_ITEM macros is strong enough to
>justify the shorter name.

I haven't had time to follow this discussion at all, but for a macro to be
called Py_SETREF and *not* increment the reference counter seems at best
confusing.  Despite my hesitation to paint a bike shed I haven't had time to
inspect, something more akin to Py_SET_POINTER seems more appropriate
(i.e. don't put "REF" in the name if it isn't playing refcounting games).

-Barry
___
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] Summary of Python tracker Issues

[Python tracker]

ACTIVITY SUMMARY (2014-02-21 - 2014-02-28)
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:
  open4582 (+24)
  closed 27999 (+62)
  total  32581 (+86)

Open issues with patches: 2073 


Issues opened (53)
==

#20693: Sidebar scrolls down 2x as fast as page content
http://bugs.python.org/issue20693  reopened by georg.brandl

#20726: inspect: Make Signature instances picklable
http://bugs.python.org/issue20726  opened by yselivanov

#20727: Improved roundrobin itertools recipe
http://bugs.python.org/issue20727  opened by david.lindquist

#20728: Remove unused import from base64
http://bugs.python.org/issue20728  opened by Claudiu.Popa

#20729: mailbox.Mailbox does odd hasattr() check
http://bugs.python.org/issue20729  opened by Rosuav

#20736: test_socket: testSendmsgDontWait needlessly skipped on Linux
http://bugs.python.org/issue20736  opened by baikie

#20737: 3.3 _thread lock.acquire() timeout and threading.Event().wait(
http://bugs.python.org/issue20737  opened by raruler

#20739: PEP 463 (except expression) implementation
http://bugs.python.org/issue20739  opened by twouters

#20741: Documentation archives should be available also in tar.xz form
http://bugs.python.org/issue20741  opened by Arfrever

#20742: 2to3 zip fixer doesn't fix for loops.
http://bugs.python.org/issue20742  opened by drj

#20744: shutil should not use distutils
http://bugs.python.org/issue20744  opened by doko

#20745: test_statistics fails in refleak mode
http://bugs.python.org/issue20745  opened by pitrou

#20746: test_pdb fails in refleak mode
http://bugs.python.org/issue20746  opened by pitrou

#20747: Charset.header_encode in email.charset doesn't take a maxlinel
http://bugs.python.org/issue20747  opened by rednaw

#20748: 3.4rc2 MSI uninstallation leaves behind ensurepip _uninstall .
http://bugs.python.org/issue20748  opened by loewis

#20749: shutil.unpack_archive(): security concerns not documented
http://bugs.python.org/issue20749  opened by jwilk

#20750: Roundtrip-test tokenize.untokenize(iterable_of_5_tuples)
http://bugs.python.org/issue20750  opened by terry.reedy

#20751: Misleading examples in the descriptor protocol documentation
http://bugs.python.org/issue20751  opened by zuo

#20752: Difflib should provide the option of overriding the SequenceMa
http://bugs.python.org/issue20752  opened by offby1

#20753: disable test_robotparser test that uses an invalid URL
http://bugs.python.org/issue20753  opened by larry

#20754: distutils should use SafeConfigParser
http://bugs.python.org/issue20754  opened by alunduil

#20756: Segmentation fault with unoconv
http://bugs.python.org/issue20756  opened by Sworddragon

#20758: mimetypes initialization order
http://bugs.python.org/issue20758  opened by chid

#20760: test_compileall test getting failed on 3.4 RC
http://bugs.python.org/issue20760  opened by vipulb

#20761: os.path.join doesn't strip LF or CR
http://bugs.python.org/issue20761  opened by ExtraVeral

#20762: SSLSocket.read() not documented
http://bugs.python.org/issue20762  opened by ebianchi

#20766: reference leaks in pdb
http://bugs.python.org/issue20766  opened by xdegaye

#20767: Some python extensions can't be compiled with clang 3.4
http://bugs.python.org/issue20767  opened by Antoine.Brodin.FreeBSD

#20768: pyconfig.h #defines macros in global namespace
http://bugs.python.org/issue20768  opened by fsateler

#20769: Reload() description is unclear
http://bugs.python.org/issue20769  opened by roysmith

#20770: Inform caller of smtplib STARTTLS failures
http://bugs.python.org/issue20770  opened by aclover

#20773: Improve docs for DynamicClassAttribute
http://bugs.python.org/issue20773  opened by ethan.furman

#20774: collections.deque should ship with a stdlib json serializer
http://bugs.python.org/issue20774  opened by acdha

#20776: Add tests for importlib.machinery.PathFinder
http://bugs.python.org/issue20776  opened by brett.cannon

#20779: Add pathlib.chown method
http://bugs.python.org/issue20779  opened by vajrasky

#20780: Shadowed (duplicate name but different body) test in test_stat
http://bugs.python.org/issue20780  opened by vajrasky

#20782: base64 module docs do not use the terms 'bytes' and 'string' c
http://bugs.python.org/issue20782  opened by r.david.murray

#20784: 'collections.abc' is no longer defined when collections is imp
http://bugs.python.org/issue20784  opened by r.david.murray

#20785: Missing symbols in Python27.lib (Windows 64bit)
http://bugs.python.org/issue20785  opened by Victor.Lazzarini

#20786: inspect.getargspec() returns wrong answer with property.__dele
http://bugs.python.org/issue20786  opened by zzzeek

#20787: typo in asyncio docs for subprocess_exec()
http://bugs.python.org/issue20787  opened by akira

#20788: distutils.msvccompiler - flags are hidden inside initialize()
http://bugs.python.org/issue20788  opened by Matt.G

[Python-Dev] Python 3.3.4150

[Burgoon, Jason]

Good day Python Dev Team -

One of our users has reported the following:

I have installed the given msi on 64 bit as per the install instructions 
document.
One of the shortcuts 'Start Menu\Programs\Python 3.3\ Module Docs' is not 
getting launched. When I launch this shortcut, it is not opening any window.
I have tried with admin user and non-admin user.

Is this expected behavior?

Please advise and thanks for your help.

Jason

[http://intranet.ds.global/technology/employees/Documents/Communication%20Resource%20Center/Small%20logo%20for%20signature.png]
Jason Burgoon
Application Management Services - Coordinator
4333 Edgewood Rd NE, Cedar Rapids, IA 52499
Phone: (319) 355-4534
Email: jason.burg...@transamerica.com
Click here to visit 
the AGT Website


<>___
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] Poll: Py_REPLACE/Py_ASSIGN/etc

[Nick Coghlan]

On 1 Mar 2014 01:22, "Barry Warsaw"  wrote:
>
> On Feb 28, 2014, at 10:27 PM, Nick Coghlan wrote:
>
> >With the new macro in place, the existing Py_CLEAR(x) macro would be
> >equivalent to Py_SETREF(x, NULL).
> >
> >Originally I was also concerned about the "how will people know there's
no
> >implicit incref?", but I've since become satisfied with the fact that the
> >precedent set by the reference stealing SET_ITEM macros is strong enough
to
> >justify the shorter name.
>
> I haven't had time to follow this discussion at all, but for a macro to be
> called Py_SETREF and *not* increment the reference counter seems at best
> confusing.  Despite my hesitation to paint a bike shed I haven't had time
to
> inspect, something more akin to Py_SET_POINTER seems more appropriate
> (i.e. don't put "REF" in the name if it isn't playing refcounting games).

It *is* playing refcounting games - it's decrefing the existing target
while stealing a reference to the new target, just like the existing
SET_ITEM macros and somewhat like Py_CLEAR (although in that case, it's
more obvious that we will never incref NULL).

The whole point of this macro is to take an *existing* reference and safely
*overwrite* another existing reference, exactly as the SET_ITEM macros do.

That actually gives me an idea that wasn't on Serhiy's original list:
Py_SET_ATTR(target, value).

After all, setting attributes safely from C is the main use case for this,
and I think it strengthens the parallel with the SET_ITEM macros on the
concrete types.

Cheers,
Nick.

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

Re: [Python-Dev] Poll: Py_REPLACE/Py_ASSIGN/etc

[Barry Warsaw]

On Mar 01, 2014, at 08:15 AM, Nick Coghlan wrote:

>It *is* playing refcounting games - it's decrefing the existing target
>while stealing a reference to the new target, just like the existing
>SET_ITEM macros and somewhat like Py_CLEAR (although in that case, it's
>more obvious that we will never incref NULL).

Okay, but "setting the reference" isn't one of them, which is what I read when
I see Py_SETREF. ;)

>The whole point of this macro is to take an *existing* reference and safely
>*overwrite* another existing reference, exactly as the SET_ITEM macros do.
>
>That actually gives me an idea that wasn't on Serhiy's original list:
>Py_SET_ATTR(target, value).

That does seem better.
-Barry


signature.asc
Description: PGP signature
___
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] Python 3.3.4150

[Jeff Allen]

Jason:

I get that too, now I try it. The place to report bugs is:

http://bugs.python.org/

However, please take a look at http://bugs.python.org/issue14512 before 
you file a new one.


Jeff Allen


On 28/02/2014 17:05, Burgoon, Jason wrote:


Good day Python Dev Team --

One of our users has reported the following:

I have installed the given msi on 64 bit as per the install 
instructions document.


One of the shortcuts 'Start Menu\Programs\Python 3.3\ Module Docs' is 
not getting launched. When I launch this shortcut, it is not opening 
any window.


I have tried with admin user and non-admin user.

Is this expected behavior?

Please adviseand thanks for your help.

Jason




___
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] Python 3.3.4150

[Terry Reedy]

On 2/28/2014 12:05 PM, Burgoon, Jason wrote:


One of the shortcuts ‘Start Menu\Programs\Python 3.3\ Module Docs’ is
not getting launched. When I launch this shortcut, it is not opening any
window.
I have tried with admin user and non-admin user.
Is this expected behavior?


No, it is a bug that I already reported.

Usage questions and problem reports like this should better be posted to 
python-list. Also, plain text is preferred to html.


--
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] Poll: Py_REPLACE/Py_ASSIGN/etc

[emm . odeke]

Sent from my BlackBerry 10 smartphone on the Koodo network.
  Original Message  
From: Barry Warsaw
Sent: Friday, February 28, 2014 3:50 PM
To: python-dev@python.org
Subject: Re: [Python-Dev] Poll: Py_REPLACE/Py_ASSIGN/etc

On Mar 01, 2014, at 08:15 AM, Nick Coghlan wrote:

>It *is* playing refcounting games - it's decrefing the existing target
>while stealing a reference to the new target, just like the existing
>SET_ITEM macros and somewhat like Py_CLEAR (although in that case, it's
>more obvious that we will never incref NULL).

Okay, but "setting the reference" isn't one of them, which is what I read when
I see Py_SETREF. ;)

>The whole point of this macro is to take an *existing* reference and safely
>*overwrite* another existing reference, exactly as the SET_ITEM macros do.
>
>That actually gives me an idea that wasn't on Serhiy's original list:
>Py_SET_ATTR(target, value).

That does seem better.
-Barry
___
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] PEP 463: Exception-catching expressions

[Glenn Linderman]

On 2/28/2014 4:51 AM, Nick Coghlan wrote:

The preferred notation in the PEP most resembles the existing lambda
use case, with "except" instead of "lambda", an exception handling
spec instead of an argument list and an additional leading expression:

 (expr except Exception: default)

Lots of people don't like the lambda notation though, so it isn't
necessarily a particularly compelling parallel to use.


Thank you for explaining why I find the above notation awkward.  ": as 
introducing a suite" never bothered me, because, as you've now 
enumerated, there are other uses of :.


But the lambda syntax parallel is what I don't like about it... I find 
the lambda syntax hard to read.



By contrast,
it's rare to hear any objections to the {key:value} dict display
syntax. Hence the proposed tweak to the syntax to define an "exception
handler expression" syntax that is analogous to a dict display rather
than a lambda expression:

 expr except (Exception: default)

However, I have realised that there*is*  a major downside to that
notation, which is that it lacks the connotations of lazy evaluation
associated with lambda expressions, whereas the default result of an
except expression won't be evaluated at all if the exception isn't
thrown.
You are overlooking that the keyword except provides exactly the 
connotation of lazy evaluation, so if this is your only reason for 
preferring the lambda syntax, you just erased it :)
___
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] PEP 463: Exception-catching expressions

[Chris Angelico]

On Sat, Mar 1, 2014 at 12:24 PM, Glenn Linderman  wrote:
> You are overlooking that the keyword except provides exactly the connotation
> of lazy evaluation, so if this is your only reason for preferring the lambda
> syntax, you just erased it :)

Statements are always executed sequentially. That's not "lazy
evaluation", that's just the way statements are :)

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