Hello! When I was writing PEP 103 I wanted to help to start using git.
There were a few proponents and a few opponents: people expressed
concerns that the PEP is too generic and isn't really related to Python
development so I promised to revoke the PEP after the switch to git and
Now I think is the time. I hope revocation of the PEP wouldn't cause
any problem? I'm gonna publish it at wiki.p.o.
Oleg Broytman http://phdru.name/ phd(a)phdru.name
Programmers don't die, they just GOSUB without RETURN.
I'm looking at stuff proposed over on Python-Ideas, and I'd appreciate
some pointers as to the basics of how C-level objects are generally
compared in Python 3.
The issue is related to the performance of PyObject_RichCompare. I got
to the point where I was trying to work out what was the _alternative_
to RichCompare. If a comparison is not "rich", then what is it? There's
a tp_richcompare slot in the type structure, but I haven't noticed
anything else obvious for simple comparison (In 2.x days - which I have
more experience with - __cmp__ was a thing which now seems to be gone. I
understand the Python-level changes with sort(..., key=foo) but I've not
looked at the underlying C implementation until now).
Anyway, I followed things as far as Objects/typeobject.c and then I got
bitten by a macro dialect that I don't immediately grok, so anything
that spells it out a bit more plainly would be nice (I can follow the
code if I need to - but a shortcut from those who know this off the top
of their head would be helpful).
Is this pattern
async def bar():
async def async_main():
considered to be valid?
The reason I'm asking is that some code out there likes to accept a
might-be-a-coroutine-function argument, using
res = await fn()
res = fn()
res = fn()
res = await res()
The former obviously breaks when somebody combines these idioms and calls
but I can't help but wonder whether the latter use might be deprecated, or
even warned about, in the future and/or with non-CPython implementations.
-- Matthias Urlichs
Hi Python Developers,
print() function has a slight design issue, when user gives start and end positions of character array.Issue: >>> str_ary="abcdef" >>> print(str_ary) b >>> print(str_ary) e >>> print(str_ary[1:4]) bcd >>>
In the above scenario, user is expecting that output of print function will be bcde (not bcd).
Analysis: I kind of figured out what could be the issue. To get the string slice, "between" (or equivalent) was used. i.e. str_ary array position >=1 and < 4 Solution: User experience will be better if the code is updated to get last character. i.e str_ary array position >=1 and <= 4
Note: To keep the code as backward compatibility, you may come up with different name like printf()
An update on the 3.6.1 release: As you probably noticed, 3.6.1 release candidate 1 was made available (finally!) two days ago. Thank you for your patience as we worked though the details of producing a release using our new GitHub-based development workflow. As we've noted, it's really important for all segments of the community to try using 3.6.1rc1 to help make sure something didn't break along the way. Please report any potential problems via the bugs.python.org tracker and mark them as "release blocker".
Because rc1 was delayed a week, I've moved the planned release date for 3.6.1 final back a week as well, now 2017-03-20. That gives two weeks of exposure for rc1. The plan is to, if at all possible, not ship any additional changes in the final beyond what is already in rc1 unless we discover any release-blocking critical problems in rc1. The 3.6 branch remains open for new cherry-pick PRs etc but you should expect that any PRs that are merged into the 3.6 branch since the v3.6.1rc1 tag will first be released in 3.6.2, expected before the end of June (about 3 months).
Again, if something critical comes up that you feel needs to be in 3.6.1, you need to make sure the issue is marked as a "release blocker" and you should make sure I am aware of it. If any such release blockers do arise, we will discuss them and decide whether they should go into 3.6.1 and whether a second release candidate is needed.
Thanks for your support!
nad(a)python.org -- 
On behalf of the Python development community and the Python 3.6 release
team, I would like to announce the availability of Python 3.6.1rc1.
3.6.1rc1 is the first release candidate for Python 3.6.1, the first
maintenance release of Python 3.6. 3.6.0 was released on 2017-12-22
to great interest and now, three months later, we are providing the
first set of bugfixes and documentation updates for it. While
3.6.1rc1 is a preview release and, thus, not intended for production
environments, we encourage you to explore it and provide feedback
via the Python bug tracker (https://bugs.python.org). Although it
should be transparent to users of Python, 3.6.1 is the first release
after some major changes to our development process so we ask users
who build Python from source to be on the lookout for any unexpected
3.6.1 is planned for final release on 2017-03-20 with the next
maintenance release expected to follow in about 3 months.
Please see "What’s New In Python 3.6" for more information:
You can find Python 3.6.1rc1 here:
More information about the 3.6 release schedule can be found here:
nad(a)python.org -- 
I've read through PEPs 483, 484, and 526, but I don't see any discussion of how type hints should work when the type of a class member differs from the type of an instance member, like when metaclasses are used to create instances.
>>> from django.db import models
>>> class MyModel(models.Model):
... name = models.CharField()
... class Meta:
... app_label = "myapp"
>>> m = MyModel()
In this case, I would like to be able to specify an instance type of str for MyModel.name.
Can someone point me to any existing relevant discussion? Or if not, where should a new discussion start?
There are a few modules that have had their constants redefined as Enums, such as signal, which has revealed a minor nit:
The resulting enumeration is neither in alpha nor value order. While this has no bearing on programmatic usage I would
like these Enums to be ordered, preferably by value.
Would anyone prefer lexicographical ordering, and if so, why?