Hi,
My question is simple: do we officially support Solaris and/or OpenIndiana?
Jesus Cea runs an OpenIndiana buildbot slave:
http://buildbot.python.org/all/buildslaves/cea-indiana-x86
"Open Indiana 32 bits"
The platform module of Python says "Solaris-2.11", I don't know the
exact OpenIndiana version.
A lot of unit tests fail on this buildbot with MemoryError. I guess
that it's related to Solaris which doesn't allow overcommit
(allocating more memory than available memory on the system), or more
simply because the slave has not enough memory.
There is now an issue which seems specific to OpenIndiana:
http://bugs.python.org/issue27847
It might impact Solaris as well, but the Solaris buildbot is offline
since "684 builds".
Five years ago, I reported a bug because the curses module of Python 3
doesn't build on Solaris nor OpenIndiana anymore. It seems like the
bug was not fixed, and the issue is still open:
http://bugs.python.org/issue13552
So my question is if we officially support Solaris and/or OpenIndiana.
If yes, how can we fix issues when we only have buildbot slave which
has memory errors, and no SSH access to this server?
Solaris doesn't seem to be officially supported in Python, so I
suggest to drop the OpenIndiana buildbot (which is failing since at
least 2 years) and close all Solaris issues as "WONTFIX".
Victor
Hello,
I'm interested to find out if debugging Python scripts with GDB is supported on OSX at all?
I'm referring to the functionality described on https://wiki.python.org/moin/DebuggingWithGdb and on http://fedoraproject.org/wiki/Features/EasierPythonDebugging.
I've tried so far various combinations of pre-compiled GDB from the homebrew package manager, locally-compiled GDB from homebrew, as well as locally compiled GDB from MacPorts, together with a pre-compiled Python 2.7, homebrew-compiled 2.7, and custom compiled Python 2.7 from the official source tarball.
My results so far were not successful. The legacy GDB commands to show a python stack trace or the local variables - do not work. And the new GDB commands (referenced on the Fedora project page) are not present at all in any of the GDB versions.
I've checked the python CI build bot tests, and it seems the new GDB commands are only successfully tested on Linux machines, and are skipped on FreeBSD, OS X, and Solaris machines.
Are the new python <-> GDB commands specific to Linux?
Are there any considerations to take in regards to debug symbols for Python / GDB on OSX?
Has anyone attempted what I'm trying to do?
I would be grateful for any advice.
And I apologize if my choice of the mailing lists is not the best.
Regards, Alex.
PEP 7 requires CPython to use C code conforming to the venerable C89
standard. Traditionally, we've been stuck with C89 due to poor C support
in MSVC. However, MSVC 2013 and 2015 implement the key features of C99.
C99 does not offer anything earth-shattering; here are the features I
think we'd find most interesting:
- Variable declarations can be on any line: removes possibly the most
annoying limitation of C89.
- Inline functions: We can make Py_DECREF and Py_INCREF inline functions
rather than unpleasant macros.
- C++-style line comments: Not an killer feature but commonly used.
- Booleans
In summary, some niceties that would make CPython hacking a little more
fun.
So, what say you to updating PEP 7 to allow C99 features for Python 3.6
(in so much as GCC and MSVC support them)?
Regards,
Benjamin
Thanks for all of your efforts in getting us to the beta phase of 3.6.0! A large number of important features and a huge amount of code were committed just prior to the b1 feature freeze 3 weekends ago. Not surprisingly, there were a number of bugs found and loose ends identified and, as a result, we've negotiated some extensions to get things in before b2. Under the current schedule there were only 3 weeks between b1 and b2 and then 4 weeks between b2 and b3; that was mainly because we pushed b1 back a week due to the development sprint. I would *really* like for us to get those remaining pieces which were granted extensions into b2 as planned. The longer they are delayed, the more risk it puts on the final steps of the release and it's really important to have a stable base for our testing efforts and those of our downstream users, like third-party developers and distributors. So I think it makes sense to move b2 back a week, giving us all an extra week to get things in for b2. Without changing the date for b3, we will now have 4 weeks between b1 and b2 and 3 weeks between b2 and b3. That gives us about 10 days from now until b2.
It would be great if you can update the issue tracker for any exempted items you have. I will try to followup with you, as needed, over the next few days on their status. Please contact me if you have any questions about the 3.6.0 schedule or about whether a change is appropriate for the beta phase.
To recap, the remaining milestones for 3.6.0:
2016-10-10, 1200 UTC: 3.6.0 beta 2 (was 10-03, remaining exempted features, bug and doc fixes)
2016-10-31: 3.6.0 beta 3 (bug and doc fixes)
2016-11-21: 3.6.0 beta 4 (important bug fixes and doc fixes)
2016-12-05 3.6.0 release candidate 1 (3.6.0 code freeze, critical bug fixes, doc fixes)
2016-12-16 3.6.0 release (3.6.0rc1 plus any necessary emergency fixes)
Thank you all again for your great efforts so far on 3.6!
--Ned
https://www.python.org/dev/peps/pep-0494/
--
Ned Deily
nad(a)python.org -- []
On 29 September 2016 at 04:26, Zachary Ware
<zachary.ware+pydev(a)gmail.com> wrote:
> On Wed, Sep 28, 2016 at 10:04 PM, Terry Reedy <tjreedy(a)udel.edu> wrote:
>> On 9/28/2016 9:57 PM, terry.reedy wrote:
>>> https://hg.python.org/cpython/rev/02eb35b79af0
>>
>>
>> (2nd try) I mistakenly null merged from 3.5 to default.
>> Should a now do a proper null merge from 3.5 to 3.6 to default?
>> Should I revert this null merge?
FYI I committed some merges (04060fa4428d and ae0c983d3c65) which
should have fixed this all up.
> You aren't the only one who's missed 3.6 since it was branched :). If
> there are changes in 3.5 that should not be in 3.6, you should go
> ahead and do a null merge from 3.5 -> 3.6 -> default. If the changes
> in 3.5 are already in 3.6, I'd just leave it as is; it will clear up
> when somebody next merges something.
In this case, my automatic merge process gave conflicts and spooky
“ambiguous merge” warnings, so in this case I think it was good to
deal with it sooner rather than later.
On 29 September 2016 at 03:04, Terry Reedy <tjreedy(a)udel.edu> wrote:
> On 9/28/2016 9:57 PM, terry.reedy wrote:
>> https://hg.python.org/cpython/rev/02eb35b79af0
>
> (2nd try) I mistakenly null merged from 3.5 to default.
> Should a now do a proper null merge from 3.5 to 3.6 to default?
Yes, I think 3.5 needs to be merged into 3.6, and the result needs to
be merged into default. I guess they are null merges because the
entries were already present in 3.6b1.
> Should I revert this null merge?
I don’t think there is much point in reverting a null merge, if there
are no actual changes to revert.
I've been lurking for a couple of months, working up the confidence to
ask the list about this behavior - I've searched through the PEPs but
couldn't find any specific reference to it.
In a nutshell, in the Python 3.5 library re patterns and search buffers
both need to be either unicode or byte strings - but the keys in the
groupdict are always returned as str in either case.
I don't know whether or not this is by design, but it would make more
sense to me if when searching a bytes object with a bytes pattern the
keys returned in the groupdict were bytes as well.
I reworked the example a little just now so it would run it on 2.7 as
well; on 2.7 the keys in the dictionary correspond to the mode of the
pattern as expected (and bytes and unicode are interconverted silently)
- code and output are inline below.
Thanks for your time,
Gordon
[Code]
import sys
import re
from datetime import datetime
data = (u"first string (unicode)",
b"second string (bytes)")
pattern = [re.compile(u"(?P<ordinal>\\w+) .*\\((?P<type>\\w+)\\)"),
re.compile(b"(?P<ordinal>\\w+) .*\\((?P<type>\\w+)\\)")]
print("*** re consistency check ***\nRun: %s\nVersion: Python %s\n" %
(datetime.now(), sys.version))
for p in pattern:
for d in data:
try:
result = "groupdict: %s" % (p.match(d) and
p.match(d).groupdict())
except Exception as e:
result = "error: %s" % e.args[0]
print("mode: %s\npattern: %s\ndata: %s\n%s\n" %
(type(p.pattern).__name__, p.pattern, d, result))
[Output]
gordon@w540:~/workspace/regex_demo$ python3 regex_demo.py
*** re consistency check ***
Run: 2016-09-25 20:06:29.472332
Version: Python 3.5.2+ (default, Sep 10 2016, 10:24:58)
[GCC 6.2.0 20160901]
mode: str
pattern: (?P<ordinal>\w+) .*\((?P<type>\w+)\)
data: first string (unicode)
groupdict: {'ordinal': 'first', 'type': 'unicode'}
mode: str
pattern: (?P<ordinal>\w+) .*\((?P<type>\w+)\)
data: b'second string (bytes)'
error: cannot use a string pattern on a bytes-like object
mode: bytes
pattern: b'(?P<ordinal>\\w+) .*\\((?P<type>\\w+)\\)'
data: first string (unicode)
error: cannot use a bytes pattern on a string-like object
mode: bytes
pattern: b'(?P<ordinal>\\w+) .*\\((?P<type>\\w+)\\)'
data: b'second string (bytes)'
groupdict: {'ordinal': b'second', 'type': b'bytes'}
gordon@w540:~/workspace/regex_demo$ python regex_demo.py
*** re
consistency check ***
Run: 2016-09-25 20:06:23.375322
Version: Python
2.7.12+ (default, Sep 1 2016, 20:27:38)
[GCC 6.2.0 20160822]
mode: unicode
pattern: (?P<ordinal>\w+) .*\((?P<type>\w+)\)
data: first string (unicode)
groupdict: {u'ordinal': u'first', u'type': u'unicode'}
mode: unicode
pattern: (?P<ordinal>\w+) .*\((?P<type>\w+)\)
data: second string (bytes)
groupdict: {u'ordinal': 'second', u'type': 'bytes'}
mode: str
pattern: (?P<ordinal>\w+) .*\((?P<type>\w+)\)
data: first string (unicode)
groupdict: {'ordinal': u'first', 'type': u'unicode'}
mode: str
pattern: (?P<ordinal>\w+) .*\((?P<type>\w+)\)
data: second string (bytes)
groupdict: {'ordinal': 'second', 'type': 'bytes'}
Wow! What a busy and productive couple of weeks it has been leading up to 3.6.0b1 and feature code freeze! Congratulations and thanks to all of you who've contributed to the amazing number of PEPs, features, bug fixes, and doc changes that have gone into 3.6.0b1! Now that feature development for 3.6 is over, the challenge is to put the finishing touches on the features and documentation, squash bugs, and test test test. The next preview release will be 3.6.0b2 scheduled for 2016-10-03.
In the cpython repo, there is now a 3.6 branch. Starting now, all changes for 3.6.0 should get pushed to the 3.6 branch and then merged to default for 3.7. New features nay continue to be pushed to the default branch for release in 3.7; no new features are now permitted in 3.6 (unless you have contacted me and we have agreed on an extension). Bug fixes appropriate for 3.5.x should get pushed to the 3.5 branch and then merged to 3.6 and then to default. I've updated the Developer's Guide to reflect the now current workflow. Let me know if you find any bugs in it. Likewise, please contact me if you have any questions about the workflow or about whether a change is appropriate for 3.6 beta.
To recap:
2016-09-12 3.6 branch open for 3.6.0; 3.7.0 feature development begins
2016-09-12 to 2016-12-04: 3.6.0 beta phase (no new features)
- push code for 3.6.0 (bug/regression/doc fixes) to the new 3.6 branch
- push code for new features to the default branch for release in 3.7
2016-10-03: 3.6.0 beta 2
2016-12-04 3.6.0 release candidate 1 (3.6.0 code freeze)
2016-12-16 3.6.0 release (3.6.0rc1 plus, if necessary, any dire emergency fixes)
2018-06 3.7.0 release (3.6.0 release + 18 months, details TBD)
Thank you all again for your great efforts so far on 3.6!
--Ned
http://cpython-devguide.readthedocs.io/en/latest/https://www.python.org/dev/peps/pep-0494/
--
Ned Deily
nad(a)python.org -- []
Hi all,
I recently shot myself in the foot by assuming that TextIO.tell
returned integers rather than opaque cookies. Specifically I was
adding an offset to the value returned by TextIO.tell. In retrospect
this doesn't make sense/
Now, I don't want to drive change simply because I failed to read the
documentation carefully, but I think the current API is very easy to
misuse. Most of the time TextIO.tell returns a cookie that is actually
an integer and adding an offset to it and seek-ing works fine.
The only indication you get that you are mis-using the API is that
sometimes tell returns a cookie that when you add an integer offset to
it will cause seek() to fail with an OverflowError.
Would it be possible to change the API to return something more
opaque? E.g.: rather than converting the C cookie structure to a long,
could it instead be converted to a bytes() object.
(I.e.: Change textiowrapper_build_cookie to use
PyBytes_FromStringAndSize rather than _PyLong_FromByteArray and
equivalent for textiowrapper_parse_cookie).
This would ensure the return value is never mis-used and is probably
also faster using bytes objects than converting to/from an integer.
Are there any downsides to this? I've made some progress developing a
patch to change this functionality. Is it worth polishing and
submitting?
Cheers,
Ben
