On Thu, 16 Aug 2018, 12:44 Jacob Solinsky, <jacobsolinsky(a)gmail.com> wrote:
> I wanted the called, jumped to function to change state in the caller.
> From what I tried to do, passing locals() cannot accomplish this. I have
> made it happen in other languages though.
> In the R language, one can do this
>
> foo = function(){
> localenv = environment()
> eval(bar, environment = localenv)
>
> The above code captures the environment of the calling function and
> executes the called function as if the calling function's local environment
> was the global environment. bar doesn't have to be a function, it can be
> any valid R expression captured with the expr() function, and everything in
> R is an expression thus allowing for the full usage code blocks. Outside of
> lisp-like languages this feat seems to usually be impossible though.
>
>
> On Thu, 16 Aug 2018, 12:34 Jonathan Fine, <jfine2358(a)gmail.com> wrote:
>
>> Hi Chris
>>
>> Steve and you wrote:
>>
>> >> there
>> >> are times where I have really wanted to access the caller's
>> environment,
>> >> not the environment where my function was defined.
>>
>> > what am I missing? can't you get that by passing locals() in to a
>> function?
>>
>> I think this will fail when values are changed. According to
>> https://docs.python.org/3/library/functions.html#locals
>> > The contents of this dictionary should not be modified; changes may not
>> affect the values of local and free variables used by the interpreter.
>>
>> I suspect that Jacob, the original poster, wants to change state, and
>> also to read changed state. Jacob, could you confirm or correct, that
>> you want the called function to be able to change state in caller (or
>> perhaps even further up the stack).
>>
>> To finish, here's an interactive example of changing the value of
>> locals().
>>
>> >>> def f(a=1): loc = locals(); yield loc; yield a
>> >>> it = f()
>> >>> ctx = next(it)
>> >>> ctx
>> {'a': 1} ## This surprised me.
>> >>>
>> >>>
>> >>> def f(a=1): loc = locals(); yield locals(); yield a
>> >>> it = f()
>> >>> ctx = next(it)
>> >>> ctx
>> {'a': 1, 'loc': {...}}
>> >>> ctx['a'] = 3
>> >>> ctx['loc']['a'] = 5
>> >>> next(it) ## Is it 1 or 3 or 5?
>> 1 ## The value of 'a' hasn't changed.
>>
>> --
>> Jonathan
>> _______________________________________________
>> Python-ideas mailing list
>> Python-ideas(a)python.org
>> https://mail.python.org/mailman/listinfo/python-ideas
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
>
This arises out of PEP 505 - None-aware operators.
I thought, a page on how None is special would be nice.
I've not found such a page on the web. We do have
===
https://docs.python.org/3/library/constants.html
None
The sole value of the type NoneType. None is
frequently used to represent the absence of a
value, as when default arguments are not passed
to a function. Assignments to None are illegal
and raise a SyntaxError.
===
So decided to start writing such a page, perhaps to be
added to the docs. All code examples in Python3.4.
Here's my first attempt. I'm sure I've missed some
important examples. Please help, if you can.
None is a keyword
==============
>>> None = 0
SyntaxError: can't assign to keyword
>>> import keyword
>>> keyword.kwlist
['False', 'None', 'True', 'and', 'as', 'assert', 'break', 'class',
'continue', 'def', 'del', 'elif', 'else', 'except', 'finally', 'for',
'from', 'global', 'if', 'import', 'in', 'is', 'lambda', 'nonlocal',
'not', 'or', 'pass', 'raise', 'return', 'try', 'while', 'with', 'yield']
The Command Line Interpreter hides None
=================================
>>> None
>>>
None is false in a boolean context
==========================
>>> bool(None)
False
Procedures return None
==================
>>> a = [3,1,2]
>>> b = a.sort()
>>> a, b
([1, 2, 3], None)
Dictionary get returns None if not found
==============================
>>> {}.get('dne') is None
True
None is default return value
=====================
>>> def fn(): pass
...
>>> fn() # No response!
>>> print(fn()) # Here's why.
None
None is used as a sentinel default value
==============================
Particularly useful when default value must be determined
in body of function.
---
def insort_right(a, x, lo=0, hi=None):
# ...
if hi is None:
hi = len(a)
---
Thank you for your attention. What have I missed?
--
Jonathan
Hi,
Please let me briefly introduce myself. I'm Marko and live in Zurich,
Switzerland. I learned Python and Django during an intership in 2007 and
followed its development ever since.
I did research in computer vision (at ETH Zurich) and now I work at
Parquery AG (Zurich, Switzerland) where we implement most of our
infra-structure in Python 3.
Cheers,
Marko
(Sorry to break threading on this. In a fit of idiocy I deleted the
original email before realising I wanted to reply.)
First off, thanks for doing this Jonathan. Documentation is usually a
thankless task, so we ought to start by thanking you!
I have a few comments on both content and style, good and bad. Starting
with style, I notice you tend to write in short sentences. This is
generally a good thing, but sometimes you make them too short. This
gets really visible when you start sentences with "And" or "But"; my old
English teacher would have menaced you with a ruler for such bad
grammar. You can start a sentence with a conjunction, but it adds extra
emphasis that you don't usually want. The start of the "Why None?"
section is a good example. It reads like:
"Sometimes a value is required. But (pay careful attention to this,
it's important and there will be a quiz later) we're not able to provide
one."
I exaggerate for effect, of course, but it would read more easily as:
"Sometimes a value is required but we're not able to provide one."
On 'None is a constant':
Erm. I think you've got carried away with simplifying this and gone
down a blind alley. None is a literal, and like any other literal can't
be rebound. Either this entire section is irrelevant or you meant to
explain that there is only one "NoneType" object.
Constant is a bit of a loaded term in Python, and I think you've fallen
foul of it here.
On 'None is the default return value':
I really dislike the term "falls off the bottom". I can't think of
anything similarly short and expressive, but I grimaced when I saw it.
The 'list gotcha' is a good example of how None is used as the default
return value and why programmers should pay attention, but it doesn't
deserve it's own subsection. It's a direct consequence of None being
the return value.
On 'None can signal failure':
Here's where I think None stops being special in the document. None can
signal failure. So False, 0, an empty string, a negative number or
pretty much anything else. If you want to have a section on how None is
used, that great, but having this in the section "How None is special"
is just wrong.
On 'None as a placeholder default':
Ditto. It's common to use None as a placeholder for a mutable type;
explaining that common gotcha here would be good.
Epigraphs:
If you're going to quote Sherman, you need to expand on the uniqueness
of None. Not doing that just makes it look irrelevant. It's not
irrelevant, it's a tigger [1]
[1] Misquoting Michael Flanders from the introduction to "The
Hippopotamus Song" on "At The Drop Of A Hat".
--
Rhodri James *-* Kynesim Ltd
I'm starting a new thread on this to make sure it receives appropriate
visibility for everyone on this list. *There are ramifications for those
involved in this whole situation* as outlined at the end of this email.
To review, this mailing list operates under the PSF Community Code of
Conduct: https://www.python.org/psf/codeofconduct/ . That means everyone is
expected to be open, considerate, and respectful. Titus and I have operated
this list such that people who don't follow the CoC get a warning, then a
temporary ban of a month or two, then a year-long ban, then a permanent ban
(and we reserve the right to skip any of these steps as we see fit based on
how bad the infraction was). Since the traffic here can get a bit heavy and
thus we don't read every email, we rely on people reporting things as
appropriate to python-ideas-owner@ if things have gotten out of hand.
And boy did things get out of hand on the "Syntactic sugar to declare
partial functions" thread. Here is what I saw play out (bolding is mine):
----------
[Abe]
Words like 'partial', 'curry', 'lambda', and 'closure' are fine for text
books, published papers, and technical discussion, *but I think they would
(or do in the case of 'lambda') harm Python*.
[Steven]
*That's an extreme overreaction*.
Do you mean to imply that there are people who looked at Python, loved
the language, but decided to use something else because they didn't like
the choice of the keyword "lambda"?
If not, in what way is Python harmed? Would it be faster if the keyword
was "function", or use less memory, or more expressive?
Remember that to millions of programmers in the world, "function" is
just as much an obscure foreign piece of jargon they have to memorise as
"lambda" is to English-speakers.
[Abe]
Extreme? I thought it was a rather benign opinion.* I'm not exactly
frothing at the mouth here. It's not like I'm declaring holy war on Python
for using the word 'lambda'.* I just think it was a mistake (and thatdeath
should come to all non-believers).
[Steve]
You've said that the choice of keyword, "lambda", has caused harm. Given
the chance to clarify what you meant,
*you stood by your comment that thechoice of keyword "lambda" has done
real, significant, non-trivial harm*
to Python (the language, or the community). Presumably you fear the same
thing will happen again if we choose "partial" (otherwise, why raise the
issue?).
[Abe]
Notice:* I never said "real, significant, non-trivial harm" anywhere* in
this entire discussion. I never said anything close to that. *Stop jamming
bullshit in my mouth* to suit your narrative that I'm "extremely
overreacting". It's not cute.
----------
The way I read this going down is Abe thought something "would harm
Python". "Harm" is a strong word to use, so Steven called it an "extreme
overreaction". Now stating it like a fact is unnecessary, abrasive, and a
bit of hyperbole. Abe thought we he thought and that's fine, but it isn't
universally considered an overreaction; it was an opinion and Abe correctly
stated it as such. Steven could have easily left out the hyperbole and
framing like a statement of fact and still made the same point.
Abe then reacted with more hyperbole as he disagreed with Steven's
statement that he was overreacting. So now we are reacting to hyperbole
with hyperbole.
Steven then reacted by overstating the strength of Abe's initial
intentions. That's a misunderstanding at best, entirely misleading at worst.
At that point Abe crossed a line and basically yelled at Steven to "stop
jamming bullshit in [his] mouth".
So how should have this been handled? First, dropping all hyperbole, not
stating opinions as facts, and not being so abrasive would have probably
stopped all of this from happening. Had Steven just said "I think that's an
overreaction; can you please clarify what harm you think happened?" then he
would have gotten the answer he wanted and Abe would not have taken
offense. Abe replying with his own hyperbole didn't help.
Steven also didn't need to misrepresent what Abe said. Choosing to
re-interpret what level of harm Abe meant was not appropriate (unless
Steven got a bit sloppy and replied from memory instead of going back and
reading the emails he was replying to).
And finally, Abe's response was totally uncalled for. I don't care how out
of line someone on this list is, you don't react like that. You come to
Titus and me and we will handle it. If you need to, step back for an hour
or day before replying if that's what it takes to not react in a rude
manner.
I shouldn't be having to explain to adults on how to communicate among
strangers of different cultures, but here we are. I did an entire PyCon US
keynote on why we need to treat open source as a series of kindnesses and
react as such: https://youtu.be/tzFWz5fiVKU?t=49m29s . If we don't treat
everything as a kindness then open source simply doesn't work and people
end up walking way from open source and the Python community.
So,* ramifications from all of this* ...
Steven, stop stating your opinion as fact and being needlessly abrasive.
Your abrasiveness in responses has pushed multiple threads to breaking
points like this before and I know you have the skills to not do that if
you chose to because I've seen it here and on other mailing lists.
Constructive conversations never need anything abrasive in them in order to
get your intentions across. Consider this a warning to scale back the tone
in response to be more respectful.
Abe, you're receiving a warning about how you eventually reacted. In the
future please just step away from the keyboard until you can react
appropriately. The way you responded to Steven is not acceptable as it
isn't respectful to others on this list and there shouldn't be "vigilante
responses"; if you feel someone has violated the CoC then tell us admins
and we will handle it.
-Brett & Titus
https://www.python.org/psf/codeofconduct/
Python Community Code of Conduct
The Python community is made up of members from around the globe with
a diverse set of skills, personalities, and experiences. It is through
these differences that our community experiences great successes and
continued growth. When you're working with members of the community,
we encourage you to follow these guidelines which help steer our
interactions and strive to keep Python a positive, successful, and
growing community.
A member of the Python community is:
Open
Members of the community are open to collaboration, whether it's on
PEPs, patches, problems, or otherwise. We're receptive to constructive
comment and criticism, as the experiences and skill sets of other
members contribute to the whole of our efforts. We're accepting of all
who wish to take part in our activities, fostering an environment
where anyone can participate and everyone can make a difference.
Considerate
Members of the community are considerate of their peers -- other
Python users. We're thoughtful when addressing the efforts of others,
keeping in mind that often times the labor was completed simply for
the good of the community. We're attentive in our communications,
whether in person or online, and we're tactful when approaching
differing views.
Respectful
Members of the community are respectful. We're respectful of others,
their positions, their skills, their commitments, and their efforts.
We're respectful of the volunteer efforts that permeate the Python
community. We're respectful of the processes set forth in the
community, and we work within them. When we disagree, we are courteous
in raising our issues.
Overall, we're good to each other. We contribute to this community not
because we have to, but because we want to. If we remember that, these
guidelines will come naturally.
Questions/comments/reports? Please write to psf(a)python.org. Note: this
email address is to all of the PSF Board of Directors and the PSF
Staff. Alternatively, you may reach Ewa Jodlowska, Director of
Operations, at ewa(a)python.org.
It would be nice if dataclasses
(https://docs.python.org/3/library/dataclasses.html#dataclasses.dataclass)
had an option to make them a sequence. This would make
dataclass(frozen=True, order=True, sequence=True)
an optionally-typed version of namedtuple. It would almost totally
supplant it except that namedtuples have a smaller memory footprint.
sequence would simply inherit from collections.abc.Sequence and implement
the two methods __len__ and __getitme__.
Best,
Neil
Hello,
Do you think it would be nice to allow with statements inside genexps or
list comprehensions? The functions __enter__ and __exit__ would be
automatically called as iterables are traversed. I am thinking of
drafting a PEP about this. Examples:
This
g = (f.read() for fn in filenames with open(fn) as f)
would be equivalent to the following use of a generator function:
def __gen():
for fn in filenames:
with open(fn) as f:
yield f.read()
g = __gen()
This
list = [f.read() for fn in filenames with open(fn) as f]
would be equivalent to the following:
list = []
for fn in filenames:
with open(fn) as f:
list.append(f.read())
--
Rudy
Hi all
I know this might be a contentious question but ...
Does anyone know of any PSF approved training or certifications for
Python developers?
There is this 10 year old page
https://wiki.python.org/psf/Certification%20Proposal but I dont see any
evidence that this was ever progressed past the discussion of it.
Assuming there is no such thing as PSF approval, are there any
certifications / training course that people would recommend, or would
recognise for someone seeking employment with them?
thanks
Patrick
[cross posted from python-uk list]
Coming back to the previous discussion about a new set of overloadable
boolean operators [1], I have an idea for overloadable boolean operators
that I think might work. The idea would be to define four new operators
that take two inputs and return a boolean result based on them. This
behavior can be overridden in appropriate dunder methods. These operators
would have similar precedence to existing logical operators. The operators
would be:
bNOT - boolean "not"
bAND - boolean "and"
bOR - boolean "or"
bXOR - boolean "xor"
With corresponding dunder methods:
__bNOT__ and _rbNOT__ (or __r_bNOT__)
__bAND__ and _rbAND__ (or __r_bAND__)
__bOR__ and _rbOR__ (or __r_bOR__)
__bXOR__ and _rbXOR__ (or __r_bXOR__)
The basic idea is that the "b" is short for "boolean", and we change the
rest of the operator to upercase to avoid confusions with the existing
operators. I think these operators would be preferably to the proposals so
far (see [1] again) for a few reasons:
1. They are not easy to mistake with existing operators. They are
clearly not similar to the existing bitwise operators like & or |, and
although they are clearly related to the "not", "and", and "or" I think
they are distinct enough that it should not be easy to confuse the two or
accidentally use one in place of the other.
2. They are related to the operations they carry out, which is also an
advantage over the existing bitwise operators.
3. The corresponding dunder methods (such as __bAND__ and _rbAND__) are
obvious and not easily confused with anything else.
4. The unusual capitalization means they are not likely to be used much
in existing Python code. It doesn't fall under any standard capitalization
scheme I am aware of.
5. At least for english the capitalization means they are not easy to
confuse with existing words. For example Band is a word, but it is not
likely to be capitalized as bAND.
As to why this is useful, the overall problem is that the current logical
operators, like and, or, and not, cannot be overloaded, which means
projects like numpy and SQLAlchemy instead have to (ab)use bitwise
operators to define their own boolean operations (for example elementwise
"and" in numpy arrays). This has a variety of problems, such not having
appropriate precedence leading to precedence errors being common, and the
simple fact that this precludes them from using the bitwise operators for
bitwise operations.
There was a proposal to allow overloading boolean operators in Pep-335 [2],
but that PEP was rejected for a variety of very good reasons. I think none
of those reasons (besides the conversation fizzling out) apply to my
proposal.
So the alternative proposal that has been floating around is to instead
define new operators specifically for this. Although there seemed to be
some support for this in principle, the actually operators so far have not
met with much enthusiasm. So far the main operators proposed so far seem
to be:
1. Double bitwise operators, such as && and ||. These have the
disadvantage of looking like they should be a type of bitwise operator.
2. the existing operators, with some non-letter character at the front and
back, like ".and.". These have the advantage that they are currently not
valid syntax in most cases, but I think are too similar to existing logical
operators, to easy to confuse, and it is not immediately obvious in what
way they should differ from existing operators. They also mean different
things in other languages.
So I think my proposal addresses the main issues raised with existing
proposals, but has the downside that it requires new keywords.
Thoughts?
[1] https://mail.python.org/pipermail/python-ideas/2015-November/037207.html
[2] https://www.python.org/dev/peps/pep-0335/
