[issue47222] subprocess.Popen() should allow capturing output and sending it to stdout and stderr
Change by Philip Prindeville : -- keywords: +patch pull_requests: +30398 stage: -> patch review pull_request: https://github.com/python/cpython/pull/32344 ___ Python tracker <https://bugs.python.org/issue47222> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47222] subprocess.Popen() should allow capturing output and sending it to stdout and stderr
New submission from Philip Prindeville : I'd like to see handlers exposes for the stdout and stderr pipe-reading threads so that I could customize what's done with the data as it's read. I might, for instance, want to: (1) accumulate it into a buffer; (2) copy it onto sys.stdout or sys.stderr, respectively; (3) send it to a logging object; or some combination of the above, possibly all of them. -- components: Library (Lib) messages: 416703 nosy: pprindeville priority: normal severity: normal status: open title: subprocess.Popen() should allow capturing output and sending it to stdout and stderr type: enhancement versions: Python 3.11 ___ Python tracker <https://bugs.python.org/issue47222> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46914] On Osx Monterey(12.x), Logging.handlers.SysLogHandler does not work
Philip Bloom added the comment: > Do you mean just adding a note to the effect that SysLogHandler won't work on > macOS 12.2 because of changes to the syslog daemon on that platform? Yes or removing the specific guidance about OSX handling on it, mostly just to reduce folks coming to ask as they transition to it. That way it comes off that you need to provide a Syslog consumer to use the handler/not to expect one to exist on the platform. Hope I'm phrasing that understandably. -- ___ Python tracker <https://bugs.python.org/issue46914> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46914] On Osx Monterey(12.x), Logging.handlers.SysLogHandler does not work
Philip Bloom added the comment: I could certainly understand that. It's a weird apple choice. If so, then it probably good to adjust https://docs.python.org/3/library/logging.handlers.html#sysloghandler since it still talks about it being expected. -- ___ Python tracker <https://bugs.python.org/issue46914> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46914] On Osx Monterey(12.x), Logging.handlers.SysLogHandler does not work
New submission from Philip Bloom :
Hello, don't file these often so apologies for any mistakes, trying to be good
python citizen here.
Checked this on the python-list first, and others reported it as reproducible.
The issue is:
On Osx Monterey(12.x), Logging.handlers.SysLogHandler does not work. It won't
throw any error but the ASL/Console.App does not see any messages from it. On
OSX Big Sur (11.x) this works just fine with the exact same code.
I think I've cut this into a small example proof that can be run to demonstrate
the issue. If this is run and any of the substrings are searched for in
Console.App when it is checking events, only the QQQ message from SysLog will
show up.
Gonna work around it likely on our end, but hope this helps it get fixed for a
future version.
---
import logging
from logging.handlers import SysLogHandler
root_logger = logging.getLogger()
root_logger.setLevel(logging.DEBUG)
basic_datefmt = '%m/%d/%Y %I:%M:%S %p'
syslog_format = logging.Formatter(fmt='SetupCDNGUI: %(message)s',
datefmt=basic_datefmt)
sys_handler = SysLogHandler(address='/var/run/syslog')
#sys_handler.encodePriority(SysLogHandler.LOG_USER, SysLogHandler.LOG_ALERT)
# Tried with the above, but didn't make a difference. Neither did not defining
the address and letting it go to local host.
sys_handler.setFormatter(syslog_format)
root_logger.addHandler(sys_handler)
# None of these will show up.
logging.critical("CCC This is a test critical")
logging.error("EEE This is a test error")
logging.info("III Still a test")
# Comparatively this sends a message received just fine
import syslog
syslog.openlog(logoption=syslog.LOG_PID, facility=syslog.LOG_USER)
syslog.syslog(syslog.LOG_NOTICE, 'QQQ test log')
--
components: macOS
messages: 414464
nosy: ned.deily, pbloom, ronaldoussoren
priority: normal
severity: normal
status: open
title: On Osx Monterey(12.x), Logging.handlers.SysLogHandler does not work
versions: Python 3.10, Python 3.7, Python 3.8, Python 3.9
___
Python tracker
<https://bugs.python.org/issue46914>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: Getting Syslog working on OSX Monterey
Grabbing latest python that does work. Good we're about to get out of the stone ages a bit here. So findings: Syslog - works in 3.10, broken against monterey in 3.6. Logging.Handlers.Sysloghandler - is broken in both against Monterey. Will bug it for the tracker. Thanks for the feedback. On Thu, Mar 3, 2022 at 10:32 AM Barry Scott wrote: > > > On 3 Mar 2022, at 03:01, Philip Bloom wrote: > > I'm probably asking on the wrong list, and probably should bother wherever > apple's ASL experts live for changes in monterey. Guess nobody else is > seeing this? > > The same exact code is working just fine on OSX Big Sur, but on OSX > Monterey it doesn't work at all. Users that haven't updated are having the > program produce logs as it has for years through > logging.handlers.SysLogHandler. Mac OSX definitely has a listening socket > at '/var/run/syslog' which shows up in Console.app. > > Apologies, Barry. I'm not quite understanding your responses. > > > This works: > > syslog.openlog(logoption=syslog.LOG_PID, facility=syslog.LOG_USER) > syslog.syslog(syslog.LOG_NOTICE, 'QQQ test log') > > I see the "QQQ test log" when I run syslog command. > > And I can reproduce that logging.handlers.SysLogHandler does not work. > I added debug to the SysLogHandler() code and see that it does indeed > write into the /var/run/syslog socket. > I suspect that macOS /var/run/syslog does not implement the RFC that this > code depends on, but that a wild guess. > > I suggest that you write your own handler that uses syslog.syslog() and > use that. > > Barry > > > When we say OSX has no listener for Syslog, what is the Apple System Log > and the general output to Console.app then? I thought that was the local > syslog on OSX and had, for years, been behaving as such when using > logging.handlers.SysLogHandler with a config in /etc/asl/ to define how it > should be routed and the rollover/cleanup frequency. > > Thanks for replying, just having trouble understanding. > > > On Mon, Feb 28, 2022 at 2:07 PM Barry Scott > wrote: > >> >> >> > On 28 Feb 2022, at 21:41, Peter J. Holzer wrote: >> > >> > On 2022-02-27 22:16:54 +, Barry wrote: >> >> If you look at the code of the logging modules syslog handle you will >> see that >> >> it does not use syslog. It’s assuming that it can network to a syslog >> listener. >> >> Such a listener is not running on my systems as far as I know. >> >> >> >> I have always assumed that if I want a logger syslog handler that I >> would have >> >> to implement it myself. So far I have code that uses syslog directly >> and have >> >> not written that code yet. >> > >> > What do you mean by using syslog directly? The syslog(3) library >> > function also just sends messages to a "syslog listener" (more commonly >> > called a syslog daemon) - at least on any unix-like system I'm familiar >> > with (which doesn't include MacOS). It will, however, always use the >> > *local* syslog daemon - AFAIK there is no standard way to open a remote >> > connection (many syslog daemons can be configured to forward messages to >> > a remote server, however). >> >> I'm re-reading the code to check on what I'm seeing. (Its been a long >> time since I last look deeply at this code). >> >> You can write to /dev/log if you pass that to >> SysLogHandler(address='/dev/log'), but the default is to use a socket >> to talk to a network listener on localhost:514. There are no deamons >> listening on port 514 on my Fedora systems or mac OS. >> >> That is not what you would expect as the default if you are using the C >> API. >> >> What you do not see used in the SyslogHandler() is the import syslog >> and hence its nor using openlog() etc from syslog API. >> >> Barry >> >> >> >> >hp >> > >> > -- >> > _ | Peter J. Holzer| Story must make more sense than reality. >> > |_|_) || >> > | | | h...@hjp.at |-- Charles Stross, "Creative writing >> > __/ | http://www.hjp.at/ | challenge!" >> > -- >> > https://mail.python.org/mailman/listinfo/python-list >> >> -- >> https://mail.python.org/mailman/listinfo/python-list >> > > > -- > Philip Bloom > Director, Services Engineering > *AppLovin Corporation* > M: (786)-338-1439 <786-338-1439> > [image: LinkedIn] <https://www.linkedin.com/company/applovin> [image: > Twitter] <https://twitter.com/AppLovin> [image: Facebook] > <https://facebook.com/AppLovin> [image: Instagram] > <https://www.instagram.com/applovin/> > [image: AppLovin] <https://www.applovin.com/> > > > > > > -- Philip Bloom Director, Services Engineering *AppLovin Corporation* M: (786)-338-1439 <786-338-1439> [image: LinkedIn] <https://www.linkedin.com/company/applovin> [image: Twitter] <https://twitter.com/AppLovin> [image: Facebook] <https://facebook.com/AppLovin> [image: Instagram] <https://www.instagram.com/applovin/> [image: AppLovin] <https://www.applovin.com/> -- https://mail.python.org/mailman/listinfo/python-list
Re: Getting Syslog working on OSX Monterey
I'm probably asking on the wrong list, and probably should bother wherever apple's ASL experts live for changes in monterey. Guess nobody else is seeing this? The same exact code is working just fine on OSX Big Sur, but on OSX Monterey it doesn't work at all. Users that haven't updated are having the program produce logs as it has for years through logging.handlers.SysLogHandler. Mac OSX definitely has a listening socket at '/var/run/syslog' which shows up in Console.app. Apologies, Barry. I'm not quite understanding your responses. When we say OSX has no listener for Syslog, what is the Apple System Log and the general output to Console.app then? I thought that was the local syslog on OSX and had, for years, been behaving as such when using logging.handlers.SysLogHandler with a config in /etc/asl/ to define how it should be routed and the rollover/cleanup frequency. Thanks for replying, just having trouble understanding. On Mon, Feb 28, 2022 at 2:07 PM Barry Scott wrote: > > > > On 28 Feb 2022, at 21:41, Peter J. Holzer wrote: > > > > On 2022-02-27 22:16:54 +, Barry wrote: > >> If you look at the code of the logging modules syslog handle you will > see that > >> it does not use syslog. It’s assuming that it can network to a syslog > listener. > >> Such a listener is not running on my systems as far as I know. > >> > >> I have always assumed that if I want a logger syslog handler that I > would have > >> to implement it myself. So far I have code that uses syslog directly > and have > >> not written that code yet. > > > > What do you mean by using syslog directly? The syslog(3) library > > function also just sends messages to a "syslog listener" (more commonly > > called a syslog daemon) - at least on any unix-like system I'm familiar > > with (which doesn't include MacOS). It will, however, always use the > > *local* syslog daemon - AFAIK there is no standard way to open a remote > > connection (many syslog daemons can be configured to forward messages to > > a remote server, however). > > I'm re-reading the code to check on what I'm seeing. (Its been a long > time since I last look deeply at this code). > > You can write to /dev/log if you pass that to > SysLogHandler(address='/dev/log'), but the default is to use a socket > to talk to a network listener on localhost:514. There are no deamons > listening on port 514 on my Fedora systems or mac OS. > > That is not what you would expect as the default if you are using the C > API. > > What you do not see used in the SyslogHandler() is the import syslog > and hence its nor using openlog() etc from syslog API. > > Barry > > > > >hp > > > > -- > > _ | Peter J. Holzer| Story must make more sense than reality. > > |_|_) || > > | | | h...@hjp.at |-- Charles Stross, "Creative writing > > __/ | http://www.hjp.at/ | challenge!" > > -- > > https://mail.python.org/mailman/listinfo/python-list > > -- > https://mail.python.org/mailman/listinfo/python-list > -- Philip Bloom Director, Services Engineering *AppLovin Corporation* M: (786)-338-1439 <786-338-1439> [image: LinkedIn] <https://www.linkedin.com/company/applovin> [image: Twitter] <https://twitter.com/AppLovin> [image: Facebook] <https://facebook.com/AppLovin> [image: Instagram] <https://www.instagram.com/applovin/> [image: AppLovin] <https://www.applovin.com/> -- https://mail.python.org/mailman/listinfo/python-list
Re: Getting Syslog working on OSX Monterey
Thanks. Had tried it with no address, which defaults to ('localhost',
'514') as well as address='/var/run/syslog' which had been working
previously, and the doc recommends as:
For example, on Linux it’s usually ‘/dev/log’ but on OS/X it’s
‘/var/run/syslog’. You’ll need to check your platform and use the
appropriate address (you may need to do this check at runtime if your
application needs to run on several platforms)
Aiming for this to be being picked up on the same computer I'm running the
test script (Python -> Logging -> SyslogHandler -> Mac OS Syslogd -> parsed
ASL config -> /var/log/Appname/Appname.log). It's why I think I may be
missing something fundamental, but it feels like something subtle changed
in the latest OSX.
On Sun, Feb 27, 2022 at 11:26 AM Dennis Lee Bieber
wrote:
> On Sun, 27 Feb 2022 08:34:21 -0800, Philip Bloom
> declaimed the following:
>
> >
> >sys_handler = SysLogHandler(address='/var/run/syslog')
>
> As I read the documentation, the address is supposed to be the
> NETWORK
> address of the machine to receive the log messages...
>
> https://docs.python.org/3/library/logging.handlers.html#sysloghandler
>
> >#sys_handler.encodePriority(SysLogHandler.LOG_USER,
> SysLogHandler.LOG_ALERT)
> ># Tried with the above, but didn't make a difference. Neither did not
> >defining the address and letting it go to local host.
> >sys_handler.setFormatter(syslog_format)
> >root_logger.addHandler(sys_handler)
> >
> >logging.critical("This is a test")
> >logging.error("This is a test error")
> >logging.info("Still a test")
> >logging.debug("Testy test")
> >
> >Using command line: Oddly, this gets to Console.Apps messages from device
> >reliably, though doesn't get picked up by syslog -w or get received by the
> >ASL config redirect:
> >syslog -s -l error -k Message "appName: this is a test2"
> >syslog -s -l notice -k Message "appName: this is a test3"
> >
> >ASL configuration, which is loaded according to syslog -config:
> >> /var/log/appName/appName.log mode=0640 compress format=std rotate=seq
> >file_max=50M all_max=500M
> >? [CA= Sender appName] file /var/log/appName/appName.log
> >
> >My end goal is really to get just a working python logging ->
> >var/log/appname/appname.log again so glad to just be pointed in the right
> >direction if way off base.
>
>
> --
> Wulfraed Dennis Lee Bieber AF6VN
> wlfr...@ix.netcom.com
> http://wlfraed.microdiversity.freeddns.org/
> --
> https://mail.python.org/mailman/listinfo/python-list
>
--
Philip Bloom
Director, Services Engineering
*AppLovin Corporation*
M: (786)-338-1439 <786-338-1439>
[image: LinkedIn] <https://www.linkedin.com/company/applovin> [image:
Twitter] <https://twitter.com/AppLovin> [image: Facebook]
<https://facebook.com/AppLovin> [image: Instagram]
<https://www.instagram.com/applovin/>
[image: AppLovin] <https://www.applovin.com/>
--
https://mail.python.org/mailman/listinfo/python-list
Getting Syslog working on OSX Monterey
Hello,
First time mailing and looking for help/guidance. Hopefully not too in the
wrong place.
We've had an app with logging to a /var/log for many years through
logging.sysloghandler. Recently, though, I noticed that it suddenly was
getting no logs whatsoever over there and investigated, believing the
recent triggering change was upgrading to Mac OSX 12 (Monterey).
My understanding is a bit primitive, but our config had never been hard to
follow previously and I may be missing something fundamental. I've looked
over a number of online examples but they don't seem to be running
correctly either. I'm on Python 3.6.8 (though we're about to start an
upgrade to the latest stable, if that in theory may have changes to syslog
handling). I'm mostly ending up here since I'm finding such differences in
response between python modules I'd expect to be fairly similar.
Separating into a test script I've been testing with logging.SysLogHandler,
syslog, and the command line 'syslog -s'. Replaced all below with a
placeholder appName but it's normally a fairly unique setupCDNGUI name.
Example with syslog (python module): - This will show up in System.log but
not in Apple's Console for all messages to device, though won't get all the
way to file.
import syslog
syslog.syslog(syslog.LOG_NOTICE, 'AppName: THIS IS A TEST - Processing
started')
syslog.syslog(syslog.LOG_ERR, 'AppName: THIS IS A TEST ERROR - Processing
started')
Example with SyslogHandler: - This doesn't seem to show up anywhere besides
the screen log, which is odd to me as reading the docs, I understood this
to be a logging integration into the syslog module, so expected similar
behavior in at least what was sent out. Syslog handler is definitely
picked up in logging.handlers
root_logger = logging.getLogger()
root_logger.setLevel(logging.DEBUG)
basic_datefmt = '%m/%d/%Y %I:%M:%S %p'
formatter = logging.Formatter(fmt='%(asctime)s %(levelname)s: %(message)s',
datefmt=basic_datefmt)
syslog_format = logging.Formatter(fmt='SetupCDNGUI: %(message)s',
datefmt=basic_datefmt)
scrhandler = logging.StreamHandler()
scrhandler.setFormatter(formatter)
root_logger.addHandler(scrhandler)
sys_handler = SysLogHandler(address='/var/run/syslog')
#sys_handler.encodePriority(SysLogHandler.LOG_USER, SysLogHandler.LOG_ALERT)
# Tried with the above, but didn't make a difference. Neither did not
defining the address and letting it go to local host.
sys_handler.setFormatter(syslog_format)
root_logger.addHandler(sys_handler)
logging.critical("This is a test")
logging.error("This is a test error")
logging.info("Still a test")
logging.debug("Testy test")
Using command line: Oddly, this gets to Console.Apps messages from device
reliably, though doesn't get picked up by syslog -w or get received by the
ASL config redirect:
syslog -s -l error -k Message "appName: this is a test2"
syslog -s -l notice -k Message "appName: this is a test3"
ASL configuration, which is loaded according to syslog -config:
> /var/log/appName/appName.log mode=0640 compress format=std rotate=seq
file_max=50M all_max=500M
? [CA= Sender appName] file /var/log/appName/appName.log
My end goal is really to get just a working python logging ->
var/log/appname/appname.log again so glad to just be pointed in the right
direction if way off base.
--
Philip Bloom
Director, Services Engineering
*AppLovin Corporation*
M: (786)-338-1439 <786-338-1439>
[image: LinkedIn] <https://www.linkedin.com/company/applovin> [image:
Twitter] <https://twitter.com/AppLovin> [image: Facebook]
<https://facebook.com/AppLovin> [image: Instagram]
<https://www.instagram.com/applovin/>
[image: AppLovin] <https://www.applovin.com/>
--
https://mail.python.org/mailman/listinfo/python-list
[issue46800] Support for pause(2)
New submission from Philip Rowlands : Went looking for os.pause() but found nothing in the docs, bpo, or Google. https://man7.org/linux/man-pages/man2/pause.2.html Obviously not a popular syscall, but I have a use case for it. -- components: Library (Lib) messages: 413554 nosy: philiprowlands priority: normal severity: normal status: open title: Support for pause(2) type: enhancement ___ Python tracker <https://bugs.python.org/issue46800> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33618] Support TLS 1.3
Change by Philip Prindeville : -- nosy: +philipp ___ Python tracker <https://bugs.python.org/issue33618> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43669] PEP 644: Require OpenSSL 1.1.1 or newer
Change by Philip Prindeville : -- nosy: +philipp ___ Python tracker <https://bugs.python.org/issue43669> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44783] SSL needs client OCSP stapling
New submission from Philip Prindeville : When TLS client certificates are used for authentication, servers need to ensure that the certificate is current and hasn't been revoked. In zero-trust and other architectures with heavy use of micro-services, server-side validation of the client certs repeatedly can be a significant burden. Forcing the client to present a signed, stapled OCSP response to the handshake eliminates this repetitive extra step. -- assignee: christian.heimes components: SSL messages: 398592 nosy: christian.heimes, pprindeville priority: normal severity: normal status: open title: SSL needs client OCSP stapling type: enhancement ___ Python tracker <https://bugs.python.org/issue44783> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44404] tkinter's after() AttributeError with functools.partial (no attribute __name__)
New submission from Philip Sundt : ``` >>> import tkinter >>> from functools import partial >>> r=tkinter.Tk() >>> r.after(500, partial(print, "lol")) Traceback (most recent call last): File "", line 1, in File "/usr/lib/python3.7/tkinter/__init__.py", line 755, in after callit.__name__ = func.__name__ AttributeError: 'functools.partial' object has no attribute '__name__' ``` -- components: Tkinter messages: 395712 nosy: phil.tgd priority: normal severity: normal status: open title: tkinter's after() AttributeError with functools.partial (no attribute __name__) type: behavior versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue44404> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43769] ipaddress module takes bytes input as valid ip address
Philip Bond added the comment: Thanks Eric. -- ___ Python tracker <https://bugs.python.org/issue43769> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43769] ipaddress module takes bytes input as valid ip address
Philip Bond added the comment: To replicate ./cidr-gen.py google.com You will see the IP variable is a Russian IP but that was a red herring, I initially thought its was a compromised module. -- ___ Python tracker <https://bugs.python.org/issue43769> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43769] ipaddress module takes bytes input as valid ip address
New submission from Philip Bond : Hi I came across an issue with the ipaddress module where it doesent raise a ValueError when passed a non IP address. Example see attached file use tabs for indents and that doesent work with the form. What happens is it when it takes b'PING' as the call to ipaddress.IPv4Address(address) as the byte value == 4 it doesent raise a ValueError as the bytes for PING are 50 49 4e 47 -- components: Unicode files: cidr-gen.py messages: 390478 nosy: ezio.melotti, philip.bond, vstinner priority: normal severity: normal status: open title: ipaddress module takes bytes input as valid ip address type: behavior versions: Python 3.6 Added file: https://bugs.python.org/file49940/cidr-gen.py ___ Python tracker <https://bugs.python.org/issue43769> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43222] Regular expression split fails on 3.6 and not 2.7 or 3.7+
Change by Philip : -- resolution: -> wont fix stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue43222> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43222] Regular expression split fails on 3.6 and not 2.7 or 3.7+
New submission from Philip :
I am receiving an unexpected behavior in using regular expressions for
splitting a string. It seems like this error exists in `python 3.6` but not
`python 2.7` and not `python 3.7+`. Below I have described a minimal example
with `tox`.
`setup.py`
```
from setuptools import setup
setup(
name='my-tox-tested-package',
version='0.0.1',
install_requires=["pytest"]
)
```
`tests/test_re.py`
```
import re
import pytest
_DIGIT_BOUNDARY_RE = re.compile(
r'(?<=\D)(?=\d)|(?<=\d)(?=\D)'
)
def test():
_DIGIT_BOUNDARY_RE.split("10.0.0")
```
`tox.ini`
```
[tox]
envlist = py27, py36, py37
requires=
pytest
[testenv]
commands =
pytest {posargs: tests}
```
```
= FAILURES
_ test
def test():
> _DIGIT_BOUNDARY_RE.split("10.0.0")
E ValueError: split() requires a non-empty pattern match.
tests/test_god.py:9: ValueError
short test summary info
==
...
test session starts
==
platform linux -- Python 3.7.5, pytest-6.2.2, py-1.10.0, pluggy-0.13.1
rootdir: /home/probinson/code
collected 1 item
tests/test_re.py .
[100%]
1 passed in 0.00s
=
summary
___
py27: commands succeeded
ERROR: py36: commands failed
py37: commands succeeded
```
--
components: Regular Expressions
messages: 386942
nosy: ezio.melotti, mrabarnett, probinso
priority: normal
severity: normal
status: open
title: Regular expression split fails on 3.6 and not 2.7 or 3.7+
type: crash
versions: Python 3.6
___
Python tracker
<https://bugs.python.org/issue43222>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41392] Syntax error rather than run time error
New submission from Philip R Brenan : a = false # Traceback (most recent call last): # File "test.py", line 1, in # a = false # NameError: name 'false' is not defined # Compilation finished successfully. Please make this a syntax error rather than a run time error as the user intention is obvious and there cannot possibly be a variable called 'false' yet. -- components: Build messages: 374252 nosy: philiprbre...@gmail.com priority: normal severity: normal status: open title: Syntax error rather than run time error type: compile error ___ Python tracker <https://bugs.python.org/issue41392> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19081] zipimport behaves badly when the zip file changes while the process is running
Philip Lee added the comment: and I got ZipImportError: bad local file header -- ___ Python tracker <https://bugs.python.org/issue19081> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19081] zipimport behaves badly when the zip file changes while the process is running
Philip Lee added the comment: The issue still remains in Python 3.8. -- nosy: +iMath versions: +Python 3.8 -Python 2.7, Python 3.4, Python 3.5, Python 3.6 ___ Python tracker <https://bugs.python.org/issue19081> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30082] hide command prompt when using subprocess.Popen with shell=False on Windows
Philip Lee added the comment: To reproduce the reported issue, one could also test with ffmpeg.exe -- ___ Python tracker <https://bugs.python.org/issue30082> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16487] Allow ssl certificates to be specified from memory rather than files.
Jan-Philip Gehrcke added the comment: I am not too attached to "my" patch, but because I love Python I really would like us to land on a solution. > However I want all changes and new additions to the SSL module to follow PEP > 543 so I can provide a PEP 543-compatible interface in the near future (3.8 > or 3.9). Christian, I wonder: did we make progress on this front? Will the stdlib in the 3.9 release make it easy to load cert and key material from memory? > Mainly to not crush the will to help and contribute Thanks Anton for your words, truly appreciated. I do not want to sound too negative, but I would like to confirm that emotionally this issue here was a bit of an unpleasant experience for me, and it certainly inhibited my intentions, energy, motivation to (try to) contribute more. Thanks, though, to all supporters here. -- versions: +Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue16487> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31140] Insufficient error message with incorrect formated string literal
Philip Rowlands added the comment:
Status as of 3.9.0a1:
==
test.py above appears fixed, i.e. reasonable error message.
$ ./python test.py
File "/home/bob/pybug/Python-3.9.0a1/test.py", line 2
hello = f"{world)}"
^
SyntaxError: f-string: unmatched ')'
==
bpo-31140.py is not as bad a initially reported, but still gives the wrong line
number.
$ ./python bpo-31140.py
File "", line 1
(a>2s)
^
SyntaxError: invalid syntax
===
And my own example which led me to this bug. The syntax error is on line 3, not
line 1.
$ cat fruit.py
pass
pass
s = f"{My favourite fruit is {apple}}"
$ ./python -V
Python 3.9.0a1
$ ./python fruit.py
File "", line 1
(My favourite fruit is {apple})
^
SyntaxError: invalid syntax
--
nosy: +philiprowlands
versions: +Python 3.9
___
Python tracker
<https://bugs.python.org/issue31140>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38941] xml.etree.ElementTree.Element inconsistent warning for bool
Philip Rowlands added the comment: I went digging through the archives, made more interesting as elementtree was imported into the standard library. AFAICT, the FutureWarning for __bool__ (or __nonzero__ in py2) appeared circa 2007-06 in version 1.3a2: http://svn.effbot.org/public/tags/elementtree-1.3a3-20070912/CHANGES - Added future warnings for "if e" (use explicit len(e) or is None test) and "e.getchildren()" (use list(e) or iteration). The docs are still there, warning about the pitfalls and suggesting "This behaviour is likely to change somewhat in ElementTree 1.3." https://effbot.org/zone/element.htm#truth-testing 12 years on, it has not, but what was the intended change (+effbot for possible context)?? I assumed on first reading that the plan was to switch bool(Element) to return True, but others have pointed out the inconsistency with len(), or having __bool__() raise an exception. My 2c would be to steer devs away from using bool(Element) as a final step, i.e. keep the existing True/False definition, warts and all, but raise a SyntaxWarning (RuntimeWarning?) with a similar message to the current FutureWarning. -- nosy: +effbot ___ Python tracker <https://bugs.python.org/issue38941> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38941] xml.etree.ElementTree.Element inconsistent warning for bool
Philip Rowlands added the comment: It's easier to justify a change in behaviour if the warning is emitted. With no legacy concerns, I would be happy for bool() to change, but I'm not the one who would receive the grumbly tickets. How about emitting the warning in the next release, then assessing the behaviour change for version n+2? -- ___ Python tracker <https://bugs.python.org/issue38941> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38941] xml.etree.ElementTree.Element inconsistent warning for bool
New submission from Philip Rowlands :
Steps to reproduce:
$ python3.7
Python 3.7.2 (default, May 13 2019, 13:52:56)
[GCC 6.3.0 20170516] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import xml.etree.ElementTree as ET
>>> bool(ET.fromstring("").find(".//c"))
False
$ python3.7
Python 3.7.2 (default, May 13 2019, 13:52:56)
[GCC 6.3.0 20170516] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys.modules['_elementtree'] = None
>>> import xml.etree.ElementTree as ET
>>> bool(ET.fromstring("").find(".//c"))
__main__:1: FutureWarning: The behavior of this method will change in future
versions. Use specific 'len(elem)' or 'elem is not None' test instead.
This is (almost) the smallest test case, but in real code what I was trying to
write was:
```
# check the result code is ok
if response.find("./result[@code='ok']"):
return True
```
The unintuitive bool() behaviour was surprising, compared to other typical True
/ False determinations on objects, and I think what the FutureWarning is trying
to avoid.
Please implement the same warning for bool(Element) in _elementtree.c as exists
in ElementTree.py. bpo29204 was making similar alignments between the versions,
but didn't consider this FutureWarning.
--
components: Library (Lib)
messages: 357642
nosy: philiprowlands
priority: normal
severity: normal
status: open
title: xml.etree.ElementTree.Element inconsistent warning for bool
type: behavior
___
Python tracker
<https://bugs.python.org/issue38941>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15436] __sizeof__ is not documented
Change by Philip Dye : -- nosy: +Philip Dye ___ Python tracker <https://bugs.python.org/issue15436> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1820] Enhance Object/structseq.c to match namedtuple and tuple api
Change by Philip Dye : -- nosy: +Philip Dye ___ Python tracker <https://bugs.python.org/issue1820> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17301] An in-place version of many bytearray methods is needed
Change by Philip Dye : -- nosy: +Philip Dye ___ Python tracker <https://bugs.python.org/issue17301> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23560] Group the docs of similar methods in stdtypes.rst
Change by Philip Dye : -- nosy: +Philip Dye ___ Python tracker <https://bugs.python.org/issue23560> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18697] Unify arguments names in Unicode object C API documentation
Change by Philip Dye : -- nosy: +Philip Dye ___ Python tracker <https://bugs.python.org/issue18697> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21861] io class name are hardcoded in reprs
Change by Philip Dye : -- nosy: +Philip Dye ___ Python tracker <https://bugs.python.org/issue21861> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37636] Deprecate slicing and ordering operations on sys.version
Change by Philip Dye : -- nosy: +Philip Dye ___ Python tracker <https://bugs.python.org/issue37636> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15987] Provide a way to compare AST nodes for equality recursively
Philip Dye added the comment: If consensus has been reached on this, I am willing to do the work. -- nosy: +Philip Dye ___ Python tracker <https://bugs.python.org/issue15987> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36692] Unexpected stderr output from test_sys_settrace
Philip Dye added the comment: Once consensus is reached, I would be happy to do the work. -- nosy: +Philip Dye ___ Python tracker <https://bugs.python.org/issue36692> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36545] Python 3.5 OOM during test_socket on make
Philip Deegan added the comment: This seems to be resolved on kernel 5.0.12 not it says "resource denied" and the test skips -- ___ Python tracker <https://bugs.python.org/issue36545> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36545] Python 3.5 OOM during test_socket on make
Change by Philip Deegan : -- stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue36545> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36545] Python 3.5 OOM during test_socket on make
New submission from Philip Deegan : Building Python 3.5.3 or 3.5.6 on my Kernel 5.0.2 Debian 9 install has runaway memory usage during "test_socket" while running make after ./configure CFLAGS="-g3 -O3 -march=native -fPIC -I/usr/include/openssl" CXXFLAGS="-g3 -O3 -march=native -fPIC -I/usr/include/openssl" --enable-shared LDFLAGS="-L/usr/lib -L/usr/lib/x86_64-linux-gnu -Wl,-rpath=/usr/lib/x86_64-linux-gnu" --prefix=$PWD --with-valgrind --enable-optimizations --with-ensurepip=install -- messages: 339541 nosy: dekken priority: normal severity: normal status: open title: Python 3.5 OOM during test_socket on make ___ Python tracker <https://bugs.python.org/issue36545> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35813] shared memory construct to avoid need for serialization between processes
Philip Semanchuk added the comment:
> On Feb 23, 2019, at 10:40 AM, Giampaolo Rodola'
> wrote:
>
>
> Giampaolo Rodola' added the comment:
>
>> We are consciously choosing to not support an atomic "create or attach".
>> This significantly simplifies the API and avoids the valid concerns raised
>> around user confusion relating to that behavior (including the use of
>> different specified 'size' values in a race) but does not preclude our
>> potentially introducing this as a feature in the future.
>
> I understand that because of *size* we cannot solve the race condition issue
> unless the user uses some sort of synchronization mechanism. FWIW I bumped
> into this lib:
> http://semanchuk.com/philip/sysv_ipc/
> ...which provides two separate APIs to "create" and "attach":
>
>>>> SharedMemory("name", IPC_CREX)
>>>> attach("name")
>
> At this point I'm agnostic about the API, which is probably just a matter of
> personal taste (e.g. one may prefer a separate SharedMemory.attach()
> classmethod or a *mode* argument accepting "x" and "a"). I see that that lib
> use shmat() on attach and shmdt() on detach. I'm not sure if that makes a
> difference, just mentioning it because your implementation doesn't do that on
> close() and perhaps it should.
attach() and detach() are particular to SysV IPC which is different from the
POSIX IPC that’s being used here. There’s no need for attach() and detach()
with POSIX shared memory.
POSIX IPC is generally simpler than SysV IPC, in part because it was developed
after SysV IPC so the developers had the benefit of experience with the older
API.
Side note: I’m the author of the sysv_ipc package you found, as well as the
posix_ipc package.
--
___
Python tracker
<https://bugs.python.org/issue35813>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35813] shared memory construct to avoid need for serialization between processes
Philip Semanchuk added the comment: Hi all, I'm the author of `posix_ipc` on which some of this code is based. I'd be happy to sign a contributor agreement in order to erase any concerns on that front. -- nosy: +osvenskan ___ Python tracker <https://bugs.python.org/issue35813> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35533] argparse standard error usage for exit / error
New submission from Philip Rowlands : Because error() mentions standard error and exit() does not, I assumed exit() did not use stderr, but it does. Please mention standard error in the description of exit(). Relevant code at: https://github.com/python/cpython/blob/3.7/Lib/argparse.py#L2482 -- assignee: docs@python components: Documentation messages: 332128 nosy: docs@python, philiprowlands priority: normal severity: normal status: open title: argparse standard error usage for exit / error type: enhancement versions: Python 3.7 ___ Python tracker <https://bugs.python.org/issue35533> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: Asyncio tasks getting cancelled
On Mon, Nov 05, 2018 at 01:57:56PM -0700, Ian Kelly wrote: > > Which is what I want in this case. Scheduling a new (long-running) task > > as a side effect, but returning early oneself. The new task can't be > > awaited right there, because the creating one should return already. > > If you want to do this in the asyncio.run main coroutine, then that > seems like a problematic design. Once the main coroutine returns, the > event loop should be considered no longer running, and any still > pending callbacks or futures won't resolve. This is only true for the small example I provided. In the actual code this is somewhere deep in the hirarchy. > > > If the goal here is for the task created by main() to complete before > > > the loop exits, then main() should await it, and not just create it > > > without awaiting it. > > > > So if this happens somewhere deep in the hirarchy of your application > > you would need some mechanism to pass the created tasks back up the > > chain to the main function? > > I haven't used asyncio.run yet myself, so take all this with a grain > of salt, but it seems to me that anything that you want to resolve > before the event loop terminates should be awaited either directly or > indirectly by the main coroutine. From the documentation: > > """ > This function always creates a new event loop and closes it at the > end. It should be used as a main entry point for asyncio programs, and > should ideally only be called once. > """ > > So I think part of the idea with this is that the asyncio.run main > coroutine is considered the main function of your async app. Once it > returns, the program should be effectively done. For example, maybe > the main coroutine spins up a web server and returns when the web > server shuts down. Again sorry for the confusion, but I don't think this is an issue with restarting loops, as this isn't happening in my application. For context: https://github.com/ldo/dbussy/issues/13 https://gist.github.com/tu500/3232fe03bd1d85b1529c558f920b8e43 It really feels like asyncio is loosing strong references to scheduled tasks, as excplicitly keeping them around helps. Also, the error messages I'm getting are the ones from here: https://github.com/python/cpython/blob/16c8a53490a22bd4fcde2efaf4694dd06ded882b/Lib/asyncio/tasks.py#L145 Which indicates that the tasks actually weren't even started at all? > If that doesn't suit your program, for instance there's no core task > to await, but you want to schedule a lot of things that need to > resolve and that the main coroutine has no way to know about, then it > may be the case that asyncio.run is not right for your use case and > you should use loop.run_forever() instead. You'll still need some > criteria for figuring out when to exit though, and it seems to me that > whatever that is you could just bundle it up in a coroutine and await > it from main. Though not really related with my actual problem, so getting off topic, but I can imagine an architecture where that would be "There aren't any running tasks any more." or even "Never." Also, I may be overlooking things, but I haven't found a way to add a task before calling run_forever(), as asyncio will then say the loop isn't running yet. So I'm not sure how you would jumpstart in that case. -- https://mail.python.org/mailman/listinfo/python-list
[issue16487] Allow ssl certificates to be specified from memory rather than files.
Jan-Philip Gehrcke added the comment: Thanks for the discussion. Since I tried to join the efforts here in 2016 two years ago I was (and still am) enthusiastic, and willing to invest quite a bit of energy. Still, we have missed the 3.6 and 3.7 releases to change something about the fact that there is no simple way to load certificate data from memory rather than files. I really appreciate the work that as been done on https://www.python.org/dev/peps/pep-0543/. It's a truly great effort. But I think the fact that we did not land a solution since 2012 is somewhat an indicator showing that building smaller chunks and showing the willingness to iterate on a solution would have led to a more tangible outcome, something that I could use right now when building Python applications (how great would that be?). Honestly, the small API changes that were discussed here for years and that I think I implemented do not seem problematic to me from a maintenance and deprecation perspective. Yes, PEP 543 proposes a more idealistic way of doing things. But I do not see how implementing PEP 543 would have been slowed down or negatively affected in any way by the last patch I proposed. https://github.com/python/cpython/pull/5162 looks very big, and C is not as much my comfort zone as is Python. Still, please let me know if you would like me to contribute! By the way, I would have _really_ liked to see the following feedback around the first time I submitted the patch: > For example it's missing several GIL releases calls. The password callback > doesn't look correct in some places. I remember that this aspect of writing the patch consumed quite a bit of my time and I operated with care, knowing the risks. I very much would have appreciated specific feedback on this. To learn, and to actually address problems. Jan-Philip -- ___ Python tracker <https://bugs.python.org/issue16487> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34221] Any plans to combine collections.OrderedDict with dict
Philip Lee added the comment: What about my last suggestion : it would be better to move "Dictionaries preserve insertion order" part at the end of the doc of https://docs.python.org/3/library/stdtypes.html#dict up below the doc for class dict(**kwarg) class dict(mapping, **kwarg) class dict(iterable, **kwarg) so that people won't miss the feature when consulting the doc. 在2018年07月26 14时46分, "Raymond Hettinger"写道: Raymond Hettinger added the comment: See the related discussion on python-dev and other tracker entries where this was discussed previously. -- nosy: +rhettinger resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue34221> ___ -- nosy: +iMath ___ Python tracker <https://bugs.python.org/issue34221> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33958] Unused variable in pure embedding example
Philip Kendall added the comment: Thanks thatiparthy :-) -- title: Unused variable in pur embedding example -> Unused variable in pure embedding example ___ Python tracker <https://bugs.python.org/issue33958> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33958] Unused variable in pur embedding example
New submission from Philip Kendall : Line 6 of the "Pure Embedding" example at https://docs.python.org/3/extending/embedding.html#pure-embedding : PyObject *pName, *pModule, *pDict, *pFunc; contains the pDict variable which is not used anywhere else in the code, giving a compiler warning. Simple fix: just remove pDict from the list of variables. I can make a PR if you need one. -- assignee: docs@python components: Documentation messages: 320436 nosy: Philip Kendall, docs@python priority: normal severity: normal status: open title: Unused variable in pur embedding example type: enhancement versions: Python 3.6 ___ Python tracker <https://bugs.python.org/issue33958> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33870] pdb continue + breakpoint
Philip Rowlands added the comment: Considering the semantics a little more, "cont 99" could be equivalent to tbreak 99 cont perhaps with an implicit clear on SIGINT. This is similar in the simple case to "until 99", except "until" stops on frame boundaries, refuses to go backwards (e.g. in a loop), and doesn't take the full range of filename / lineno / function / condition. -- ___ Python tracker <https://bugs.python.org/issue33870> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33894] tempfile.tempdir cannot be unset
Philip Rowlands added the comment: Thanks for the edit. I did try a PR but was defeated by build/doc tool's recent version requirements (and didn't want to send untested changes, however minor). The reason for getting rid of "unset" is the confusion of "state", i.e. it has never been assigned to, or "action", i.e. the user is unsetting it. -- ___ Python tracker <https://bugs.python.org/issue33894> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33894] tempfile.tempdir cannot be unset
Philip Rowlands added the comment: How about - If tempdir is unset or None at any call to + If tempdir is None (the default) at any call to This avoids headaches over the meaning of "unset", and accurately reflects the code at: https://github.com/python/cpython/blob/3.6/Lib/tempfile.py#L289 -- ___ Python tracker <https://bugs.python.org/issue33894> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33894] tempfile.tempdir cannot be unset
New submission from Philip Rowlands : Quoting https://docs.python.org/3/library/tempfile.html """ tempfile.tempdir When set to a value other than None, this variable defines the default value for the dir argument to the functions defined in this module. If tempdir is unset or None at any call to any of the above functions except gettempprefix() it is initialized following the algorithm described in gettempdir(). """ "If tempdir is unset ..." is not true: $ python3 -c 'import tempfile; del tempfile.tempdir; t = tempfile.mkdtemp()' Traceback (most recent call last): File "", line 1, in File "/usr/lib/python3.2/tempfile.py", line 298, in mkdtemp dir = gettempdir() File "/usr/lib/python3.2/tempfile.py", line 238, in gettempdir if tempdir is None: NameError: global name 'tempdir' is not defined No strong preference whether the docs change to match the implementation, or vice-versa. -- messages: 319867 nosy: philiprowlands priority: normal severity: normal status: open title: tempfile.tempdir cannot be unset type: crash ___ Python tracker <https://bugs.python.org/issue33894> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33870] pdb continue + breakpoint
New submission from Philip Rowlands : Please extend pdb's continue to support an optional argument, identical to break. When debugging I frequently want to quickly run to a certain line number then break. Rather than break / continue / clear (or tbreak / continue), it would be handy to type (Pdb) cont 99 to run to line 99 as a one-off breakpoint. -- messages: 319622 nosy: philiprowlands priority: normal severity: normal status: open title: pdb continue + breakpoint type: enhancement ___ Python tracker <https://bugs.python.org/issue33870> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16487] Allow ssl certificates to be specified from memory rather than files.
Jan-Philip Gehrcke <jgehr...@gmail.com> added the comment: Hello! I would very much appreciate if we can find a way for us to get another review for the last patch. I did most of the work in August 2016 and got a review from Senthil and Christian which I processed. When I got back to the patch for converting it to the GitHub workflow about a year later I realized that the details faded from my mind. 4 months later, after re-digging into the details, I went into the patch again and resolved the merge conflicts that accumulated over time. Antoine kindly left another round of comments which I replied to. Now, 2 months after that last effort I'd like to not forget about the details again, but instead be able to respond to review feedback while still being on top of the matter. So, any kind and level of feedback would be greatly appreciated. Thank you! -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue16487> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16487] Allow ssl certificates to be specified from memory rather than files.
Jan-Philip Gehrcke <jgehr...@gmail.com> added the comment: Hey Antoine, Christian, Senthil! I have invested quite a bit more time to double-check my responses to the questions asked so far, clarified where appropriate, and updated the pull request on GitHub after manually resolving the merge conflicts that accumulated over time. I would very much appreciate to get another round of feedback. Can we somehow expedite this? I am available for pushing this further, so that maybe we can still land this in 3.7 after we missed 3.6 last year. Based on the diff this change _appears_ to be risky but I would like to stress again that I approached this issue pretty conservatively. I tried to make this a conceptually backwards-compatible change by keeping the old code path intact (the old tests pass, too, but this is not the best criterion here). Cheers and thanks! Jan-Philip -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue16487> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26858] setting SO_REUSEPORT fails
Philip Jenvey added the comment: Note that this isn't an android specific issue: See issue19901, and 9791c5d55f52 for an appropriate solution patch. (Renaming title) -- nosy: +pjenvey title: android: setting SO_REUSEPORT fails -> setting SO_REUSEPORT fails ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue26858> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16487] Allow ssl certificates to be specified from memory rather than files.
Jan-Philip Gehrcke added the comment: Hey Senthil and Christian! > Could you convert your latest patch into PR against > https://github.com/python/cpython That was fun. There we go: https://github.com/python/cpython/pull/2449 I hope I was not too late with that for the 3.7 development. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue16487> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16487] Allow ssl certificates to be specified from memory rather than files.
Changes by Jan-Philip Gehrcke <jgehr...@gmail.com>: -- pull_requests: +2506 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue16487> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19717] resolve() fails when the path doesn't exist
Changes by Philip Ridout <phill.rid...@gmail.com>: -- nosy: +Philip Ridout ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue19717> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30082] hide command prompt when using subprocess.Popen with shell=False on Windows
New submission from Philip Lee: First, It is nearly useless for the command prompt to pop up during the running time of subprocess.Popen with shell=False. Second, the popping up command prompt would interrupt users and do bad to user experience of GUI applications. Third, I found QProcess within Qt won't pop up the command prompt in using. It would be convenient to add an argument to suppress the command prompt from popping up when using subprocess.Popen with shell=False on Windows, many users are missing the feature and these are many similar feature request questions like the following http://stackoverflow.com/questions/7006238/how-do-i-hide-the-console-when-i-use-os-system-or-subprocess-call http://stackoverflow.com/questions/1765078/how-to-avoid-console-window-with-pyw-file-containing-os-system-call/12964900#12964900 http://stackoverflow.com/questions/1016384/cross-platform-subprocess-with-hidden-window -- components: Library (Lib) messages: 291760 nosy: iMath priority: normal severity: normal status: open title: hide command prompt when using subprocess.Popen with shell=False on Windows type: enhancement ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30082> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30079] Explain why it is recommended to pass args as a string rather than as a sequence If shell is True
New submission from Philip Lee: The doc here https://docs.python.org/3/library/subprocess.html#subprocess.Popen says : "If shell is True, it is recommended to pass args as a string rather than as a sequence." but without explain why ? Please add the explanation ! while in https://docs.python.org/3/library/subprocess.html#frequently-used-arguments says: "args is required for all calls and should be a string, or a sequence of program arguments. Providing a sequence of arguments is generally preferred, as it allows the module to take care of any required escaping and quoting of arguments (e.g. to permit spaces in file names). If passing a single string, either shell must be True (see below) or else the string must simply name the program to be executed without specifying any arguments." In the case of shell =True , I found providing a sequence of arguments rather than a string argument can take the advantage of auto escaping and quoting of arguments (e.g. to permit spaces in file names) , so what is the advantage of pass args as a string rather than as a sequence as says in the doc when shell is True? -- assignee: docs@python components: Documentation messages: 291733 nosy: docs@python, iMath priority: normal severity: normal status: open title: Explain why it is recommended to pass args as a string rather than as a sequence If shell is True type: enhancement ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30079> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30023] Example code becomes invalid for "Why do lambdas defined in a loop with different values all return the same result?"
New submission from Philip Lee: There example code here becomes invalid https://docs.python.org/3/faq/programming.html#why-do-lambdas-defined-in-a-loop-with-different-values-all-return-the-same-result >>> squares = [] >>> for x in range(5): squares.append(lambda: x**2) >>> squares [ at 0x01FB7A08>, at 0x01F82390>, at 0x01FBA3D8>, at 0x01FBA420>, at 0x01FBA468>] >>> There returned value is a List of lambda functions, not numbers -- assignee: docs@python components: Documentation messages: 291353 nosy: docs@python, iMath priority: normal severity: normal status: open title: Example code becomes invalid for "Why do lambdas defined in a loop with different values all return the same result?" type: enhancement versions: Python 3.6 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30023> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29074] repr doesn't give full result for this re math result
Philip Lee added the comment: I think so, the current behavior is misleading 在2016年12月27 00时08分, "R. David Murray"<rep...@bugs.python.org>写道: R. David Murray added the comment: If it is truncated, should it end with '...' or [...]? -- nosy: +r.david.murray ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29074> ___ -- nosy: +iMath ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29074> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16487] Allow ssl certificates to be specified from memory rather than files.
Jan-Philip Gehrcke added the comment: Christian, Senthil, would appreciate if I got another round of feedback (in the review thread) :-) -- nosy: +orsenthil ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue16487> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16487] Allow ssl certificates to be specified from memory rather than files.
Jan-Philip Gehrcke added the comment: Thanks Christian, much appreciated. Just responded to your review. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue16487> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16487] Allow ssl certificates to be specified from memory rather than files.
Jan-Philip Gehrcke added the comment: Hello! Like everybody in this thread I would love to see this land and have prepared a new patch, hoping that we can process this still for 3.6. Antoine summarized the core task here very well: > Let's stay focused on what is > necessary to solve this use case, IMO (i.e. specify non-file-backed data > as a certification chain or private key). What follows is what I believe is the consensus in this thread about a minimum viable solution (points mentioned earlier, enriched with some detail): - The `certfile` and `keyfile` arguments to `SSLContext.load_cert_chain()` can both be either a file path or a file object. - `str` or `bytes` values to both, `certfile` and `keyfile`, are interpreted as paths. - The `password` behavior must stay as is, independent of `certfile`/`keyfile` being file object or path. - When handing file paths to `load_cert_chain()`, the behavior must stay as is, in all detail. - When handing file objects to `load_cert_chain()`, - use the OpenSSL API call `PEM_read_bio_PrivateKey()` for loading the key data (reading PEM data is what's currently supported). - support the case where the `certfile` file object first presents a private key and then (a) certificate(s), as currently documented: """ Often the private key is stored in the same file as the certificate; in this case, only the certfile parameter to SSLContext.load_cert_chain() and wrap_socket() needs to be passed. If the private key is stored with the certificate, it should come before the first certificate in the certificate chain: """ Ref: - https://docs.python.org/3/library/ssl.html#combined-key-and-certificate - resemble the OpenSSL API call `SSL_CTX_use_certificate_chain_file()` behavior for loading the certificate data (as this is what's currently used in the `SSLContext.load_cert_chain()` implementation in _ssl.c. There is no direct correspondence for this function reading the data directly from memory BIOs. Relevant documentation for resembling that behavior: """ SSL_CTX_use_certificate_chain_file() adds the first certificate found in the file to the certificate store. The other certificates are added to the store of chain certificates using SSL_CTX_add1_chain_cert. """ """ For a longer chain, the client must send the complete chain [...]. This can only be accomplished by either adding the intermediate CA certificates into the trusted certificate store for the SSL_CTX object [...], or by adding the chain certificates using the SSL_CTX_add_extra_chain_cert function, """ """ When building its own certificate chain, an OpenSSL client/server will try to fill in missing certificates from CAfile/CApath, if the certificate chain was not explicitly specified (see SSL_CTX_add_extra_chain_cert, SSL_CTX_use_certificate. """ Refs: - https://github.com/python/cpython/blob/0852878a81edd5c16776a68ce34c45cca233deae/Modules/_ssl.c#L2824 - https://www.openssl.org/docs/manmaster/ssl/SSL_CTX_use_certificate.html - https://www.openssl.org/docs/manmaster/ssl/SSL_CTX_set_client_cert_cb.html - https://www.openssl.org/docs/manmaster/ssl/SSL_CTX_load_verify_locations.html When inspecting the OpenSSL code for SSL_CTX_use_certificate_chain_file(), some of the above statements are not entirely correct. After inspection, to me the safest bet seems to keep the memory/BIO-based load_cert_chain() implementation as close as possible to SSL_CTX_use_certificate_chain_file() from OpenSSL 1.0.2h: https://fossies.org/dox/openssl-1.0.2h/ssl__rsa_8c_source.html#l00685 use_certificate_chain_file() in OpenSSL 1.1.0-pre6: https://fossies.org/dox/openssl-1.1.0-pre6/ssl__rsa_8c_source.html#l00599 Using this as a template (instead of coming up with a solution purely based on OpenSSL docs) ensures that this part of the current `SSLContext.load_cert_chain()` docs will be remain correct: """ The certfile [...] in PEM format containing the certificate as well as any number of CA certificates needed to establish the certificate’s authenticity. """ More behavioral detail that I planned with: - `certfile` and `keyfile`, if given both, must both be a file path or both be a file object. A mixture is undefined behavior and leads to an error depending on the specifics of the mixture. - If `certfile` and `keyfile` are not file paths, expect them to have a read() method and just call it. Let a TypeError or AttributeError be handled by the caller (as done elsewhere in the stdlib). - Use the existing Python MemoryBIO abstractions introduced by Geert Jansen in this beautiful patch: https://gith
[issue27682] Windows Error 10053, ConnectionAbortedError: [WinError 10053] An established connection was aborted by the software in your host machine
Philip Lee added the comment:
I use the following django view function also produce the same exception
def sendFiles(request):
fileName = request.GET['fileName']
pathToFile = os.path.join(filesDir, fileName)
response = FileResponse(open(pathToFile, 'rb'))
response['Content-Type'] = 'application/octet-stream'
response[
'Content-Disposition'] = 'attachment; fileName="{}"'.format(fileName)
response['Content-Length'] = os.path.getsize(pathToFile)
# HttpResponse(open(os.path.join(os.getcwd(), 'LYYDownloaderServer.log'),
'r'), content_type='text/plain')
return response
Tested with sending file Git-2.8.4-32-bit.exe (29.8MB), if tested with sending
file GitHubSetup.exe(670kb),then no exception occurred.
the exception like the following
return self._sock.send(b)
ConnectionAbortedError: [WinError 10053] 您的主机中的软件中止了一个已建立的连接
。
[09/Aug/2016 10:30:13] "GET /FileHost/?fileName=Git-2.8.4-32-bit.exe HTTP/1.1" 5
00 59
Exception happened during processing of request from ('127.0.0.1', 62237)
Traceback (most recent call last):
File "C:\Users\i\AppData\Local\Programs\Python\Python35-32\lib\wsgiref\handler
s.py", line 138, in run
self.finish_response()
File "C:\Users\i\AppData\Local\Programs\Python\Python35-32\lib\wsgiref\handler
s.py", line 180, in finish_response
self.write(data)
File "C:\Users\i\AppData\Local\Programs\Python\Python35-32\lib\wsgiref\handler
s.py", line 274, in write
self.send_headers()
File "C:\Users\i\AppData\Local\Programs\Python\Python35-32\lib\wsgiref\handler
s.py", line 332, in send_headers
self.send_preamble()
File "C:\Users\i\AppData\Local\Programs\Python\Python35-32\lib\wsgiref\handler
s.py", line 255, in send_preamble
('Date: %s\r\n' % format_date_time(time.time())).encode('iso-8859-1')
File "C:\Users\i\AppData\Local\Programs\Python\Python35-32\lib\wsgiref\handler
s.py", line 453, in _write
result = self.stdout.write(data)
File "C:\Users\i\AppData\Local\Programs\Python\Python35-32\lib\socket.py", lin
e 593, in write
return self._sock.send(b)
ConnectionAbortedError: [WinError 10053] 您的主机中的软件中止了一个已建立的连接
。
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "C:\Users\i\AppData\Local\Programs\Python\Python35-32\lib\wsgiref\handler
s.py", line 141, in run
self.handle_error()
File "C:\Users\i\AppData\Local\Programs\Python\Python35-32\lib\site-packages\d
jango\core\servers\basehttp.py", line 92, in handle_error
super(ServerHandler, self).handle_error()
File "C:\Users\i\AppData\Local\Programs\Python\Python35-32\lib\wsgiref\handler
s.py", line 368, in handle_error
self.finish_response()
File "C:\Users\i\AppData\Local\Programs\Python\Python35-32\lib\wsgiref\handler
s.py", line 180, in finish_response
self.write(data)
File "C:\Users\i\AppData\Local\Programs\Python\Python35-32\lib\wsgiref\handler
s.py", line 274, in write
self.send_headers()
File "C:\Users\i\AppData\Local\Programs\Python\Python35-32\lib\wsgiref\handler
s.py", line 331, in send_headers
if not self.origin_server or self.client_is_modern():
File "C:\Users\i\AppData\Local\Programs\Python\Python35-32\lib\wsgiref\handler
s.py", line 344, in client_is_modern
return self.environ['SERVER_PROTOCOL'].upper() != 'HTTP/0.9'
TypeError: 'NoneType' object is not subscriptable
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "C:\Users\i\AppData\Local\Programs\Python\Python35-32\lib\socketserver.py
", line 625, in process_request_thread
self.finish_request(request, client_address)
File "C:\Users\i\AppData\Local\Programs\Python\Python35-32\lib\socketserver.py
", line 354, in finish_request
self.RequestHandlerClass(request, client_address, self)
File "C:\Users\i\AppData\Local\Programs\Python\Python35-32\lib\site-packages\d
jango\core\servers\basehttp.py", line 99, in __init__
super(WSGIRequestHandler, self).__init__(*args, **kwargs)
File "C:\Users\i\AppData\Local\Programs\Python\Python35-32\lib\socketserver.py
", line 681, in __init__
self.handle()
File "C:\Users\i\AppData\Local\Programs\Python\Python35-32\lib\site-packages\d
jango\core\servers\basehttp.py", line 179, in handle
handler.run(self.server.get_app())
File "C:\Users\i\AppData\Local\Programs\Python\Python35-32\lib\wsgiref\handler
s.py", line 144, in run
self.close()
File "C:\Users\i\AppData\Local\Programs\Python\Python35-32\lib\wsgiref\simple_
server.py", line 36, in close
self.status.split(' ',1)[0], self.bytes_sent
AttributeError: 'NoneType' object has no attribute 'split'
[09/Aug/2016 10:30:13]
[issue26800] Don't accept bytearray as filenames part 2
Philip Jenvey added the comment: Thanks Serhiy, I did not see the python-dev thread. This coincidentally came up recently in pypy3. +1 for some kind of deprecation period needed -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26800> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26754] PyUnicode_FSDecoder() accepts arbitrary iterable
Philip Jenvey added the comment: See issue26800 for reasoning to go with #4 -- nosy: +pjenvey ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26754> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26800] Don't accept bytearray as filenames part 2
New submission from Philip Jenvey: Basically a reopen of the older issue8485 with the same name. It was decided there to drop support for bytearray filenames -- partly because of the complexity of handling buffers but it was also deemed to just not make much sense. This regressed or crept back into the posix module with the big path_converter changes for 3.3: https://hg.python.org/cpython/file/ee9921b29fd8/Lib/test/test_posix.py#l411 IMHO this functionality should be deprecated/removed per the original discussion, or does someone want to reopen the debate? The os module docs (and path_converter's own docs) explicitly advertise handling of str or bytes, not bytearrays or buffers. Even os.fsencode rejects bytearrays/buffers. Related to issue26754 -- further inconsistencies around filename handling -- assignee: larry components: Interpreter Core keywords: 3.3regression messages: 263694 nosy: Ronan.Lamy, haypo, larry, pitrou, pjenvey, serhiy.storchaka priority: normal severity: normal status: open title: Don't accept bytearray as filenames part 2 type: behavior versions: Python 3.6 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26800> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26648] csv.reader Error message indicates to use deprecated
New submission from Philip Martin: Currently, the error message: _csv.Error: new-line character seen in unquoted field - do you need to open the file in universal-newline mode? is cryptic in that universal line mode has been deprecated, and will not run in Python 3.5., i.e.: open(escape_path, "rU", encoding=ENCODING) >>> DeprecationWarning: 'U' mode is deprecated I think a message indicating a suggestion to open the file with newline='' to enable universal line mode is more insightful. -- messages: 262502 nosy: Philip Martin priority: normal severity: normal status: open title: csv.reader Error message indicates to use deprecated type: enhancement versions: Python 3.5 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26648> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6634] sys.exit() called from threads other than the main one: undocumented behaviour
Jan-Philip Gehrcke added the comment: Martin, I very much like the order you suggested, thanks. I did not feel confident enough for re-structuring the entire entry. So, can we agree on using that for Python 2.7? Is there a consensus regarding the approach to take for Python 3.5? Except from Martin there was no feedback on the patch. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6634 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6634] sys.exit() called from threads other than the main one: undocumented behaviour
Changes by Jan-Philip Gehrcke jgehr...@gmail.com: Added file: http://bugs.python.org/file38096/issue6634_py27.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6634 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23427] Python should expose command when invoked with -c
Jan-Philip Gehrcke added the comment: Victor, I support the idea of sys.command. However, it would be unpopulated most of the time (e.g. set to None by default). Now, is that something we should push forward or not? I would work on a patch, but we should have an agreement first, I guess. Mihail, the original argv becomes modified in the very early bootstrap phase, and the command gets lost within that process: it gets *overwritten* with -c, which is exactly why you are observing two -c. This happens here: https://hg.python.org/cpython/file/default/Modules/main.c#l684 So, no, without a code change in main.c there will be no way to retain the command for later usage. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23427 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23427] Python should expose command when invoked with -c
New submission from Jan-Philip Gehrcke: When Python is invoked with the `-c command` switch, the command string does not get exposed in sys.argv: $ python -c import sys; print(sys.argv) ['-c'] $ python -c import sys; print(sys.argv) arg1 ['-c', 'arg1'] The command string does not get exposed anywhere, AFAIK, so it is inaccessible from within Python programs. There might be application scenarios in which it is useful to access the command string, such as for debugging purposes. One scenario is when a Python session should be able to re-spawn itself in a subprocess (I came across this question on StackOverflow: http://stackoverflow.com/q/28412903/145400) I propose to make the command string accessible. If you agree that it might make sense, the question is *how/where* to expose it. One possible way is to retain it in sys.argv, as in this example: $ python -c import sys; print(sys.argv) arg1 ['-c', 'import sys; print(sys.argv)', 'arg1'] The current sys.argv docs say If the command was executed using the -c command line option to the interpreter, argv[0] is set to the string '-c'. This sentence could then be adjusted to [...], argv[0] is set to the string '-c', and argv[1] contains the command. This method breaks existing applications that are started with the -c method and that consume command line arguments in a sys.argv[1:] fashion. The tests in Lib/test/test_cmd_line.py all pass, however. A second method would be to change sys.argv[0] from '-c' to '-c command'. This would break existing applications that check for sys.argv[0] == 'c'. A third method would be to leave sys.argv as it is, and expose the command with a new attribute in the sys module. I have attached a patch for variant 1 (passes all tests in Lib/test/test_cmd_line.py), to demonstrate which code is affected: the translation from the real argv to sys' argv is triggered in Modules/main.c. The patch does not change behavior of '-m' (it's funny, however, that the current version of main.c at first replaces the module string with '-m', whereas the runpy module later on replaces '-m' with the path to the module file anyway.). As a side node, I figure that the sys.argv documentation should be adjusted to properly reflect the -m behavior, which is: $ ./python -m testmodule foo testmodule sys.argv: ['/data/local/pythondev/pythontip/cpython/testmodule.py', 'foo'] Let me hear your comments, and I am willing to work on code and doc patches, thanks! -- assignee: docs@python components: Documentation, Interpreter Core files: sys_argv_cmd.patch keywords: patch messages: 235633 nosy: docs@python, georg.brandl, haypo, jgehrcke, pitrou priority: normal severity: normal status: open title: Python should expose command when invoked with -c type: enhancement versions: Python 3.5, Python 3.6 Added file: http://bugs.python.org/file38065/sys_argv_cmd.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23427 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6634] sys.exit() called from threads other than the main one: undocumented behaviour
Jan-Philip Gehrcke added the comment: I'd love to find an agreement here. I think we are quite close to getting this closed, so further input is very welcome. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6634 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20709] os.utime(path_to_directory): wrong documentation for Windows.
Jan-Philip Gehrcke added the comment: Can these super-small doc patches get applied or should we change something? Thanks! -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20709 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6634] sys.exit() called from threads other than the main one: undocumented behaviour
Jan-Philip Gehrcke added the comment: Thanks for your feedback Antoine. I'm not sure what the doc patch achieves. Let me try to bring things in order. It should achieve two things: 1. Properly describe the stderr-writing behavior of sys.exit(). === Current 2.7 docs: ..., and any other object is printed to stderr. This is wrong in its generality and requires clarification. Agreed? How would you improve the docs in this regard? This is the reasoning I had in mind: We could change the original sentence, but IMO it then contains too many pieces of important information and becomes difficult to digest, e.g.: If another type of object is passed, None is equivalent to passing zero, and any other object is printed to stderr (only when called in the main thread) and results in an exit code of 1.. Difficult, right? I thought about removing the stderr part from this sentence and discussing this topic separately, in simpler sentences. But: I think the stderr part needs to stay in the original sentence, because it clarifies how different argument types are dealt with. Then I took another point of view: we have acknowledged that the behavior is problematic, we just cannot change it anymore for 2.7. The direct consequence from this point of view is to warn about current behavior. 6 years ago, I took the docs literally and relied on getting proper error messages printed to stderr. And I didn't get those. I would have appreciated a warning, I guess. With this being said, I'd love to look at an alternative proposal of how we could change the docs in this regard. 2. Clarify that when called from a thread, the thread exits silently Current 2.7 docs: Since exit ultimately only raises an exception, it will only exit the process when called from the main thread. This sentence is problematic. It relates a cause to an effect, and this relation is wrong or at least incomplete. The only valuable information left in the sentence is the *effect*, without providing an explanation. I would rather want to take the inverse approach, and explain the *cause* as correct as possible. In other words: the above sentence misses to explain what actually happens when sys.exit() is called in a non-primary thread. The actual behavior and cause for mentioned effect is, as far as I am aware: If raised in a non-primary thread, SystemExit is caught automatically and causes the calling thread to exit silently. This is what I added as a note. And I think that we agree that this cause may have many effects, whereas only one of them is that sys.exit() called from a non-primary thread can not terminate the process. It only states more verbosely what is already said in the current version. I hope to have convinced you that this is not true. Also, warnings are really for important issues (such as security issues); using them too liberally is a disservice to the reader. I agree. I really think that both points need to be addressed in the docs, and I have now clarified my reasoning, but am very open to further suggestions. And I really do not want to make a strong point about whether things should end up in red or blue boxes :-). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6634 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18454] distutils crashes when uploading to PyPI having only the username (no pw) defined
Changes by Jan-Philip Gehrcke jgehr...@gmail.com: Added file: http://bugs.python.org/file38006/issue18454_py27_prompt_test.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18454 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18454] distutils crashes when uploading to PyPI having only the username (no pw) defined
Jan-Philip Gehrcke added the comment: First, I want to address the situation in 2.7. Please have a look at my patch and my reasoning. This is my setup.py test file content: from distutils.core import setup setup(name='foo', version='1.0', packages=['testpackage']) This is the current situation for 2.7 head, in summary: 1) Without a proper .pypirc file in place, uploading fails with Upload failed (401): You must be identified to edit package information 2) With a valid .pypirc in place which does not define a password this exception is raised: TypeError: cannot concatenate 'str' and 'NoneType' objects (1) happens due to the fact that the default username/password strings are empty, but the request is still fired against PyPI. This obviously fails. This could be fixed by prompting for both, username and password or by aborting before sending the request. However, this would be quite a significant change in behavior. I think we should not do this, because AFAIK the 2.7 documentation does not specify what the behavior should be *without* existing .pypirc file. So, I think there might not be enough reason to consider such a change a bug fix. What do you think? (2) violates the docs and I guess this is what Nick meant when he said that the stdlib should be updated. I propose a patch so that what the docs say (If omitted, the user will be prompt to type it when needed) is what actually happens. The patch consists of two parts: Part A: issue18454_py27_prompt.patch This uses getpass/sys.stdin.readline() for retrieving the password, depending on whether the process is attached to a tty or not, respectively. The config parsing and value propagation is a little messy in the command/upload.py module, so I have also added comments for clarity and simplified the logic a little. Part B: issue18454_py27_prompt_test.patch - Here it gets messy. Normally, we want to have a new test case that fails before applying patch A, and succeeds after applying it. However, here we actually have to deal with an already existing bogus test case which succeeds before and fails after A gets applied. A very bad sign, usually. But in this case I am of the strong opinion that we can and have to change the test implementation, because: - the test actually makes sure that `cmd.password` is set to None when `cmd.finalize_options()` has done its work. However,`cmd.password` being None leads to the TypeError exception described above. That is, this test case basically ensures the very existance of the bug that we want to fix. - it has a suspiciously useless name. It is called `test_saved_password`, but actually tests the case when no password is saved in .pypirc. - this test actually has quite low code coverage. AFAIK it *only* tests the behavior of `cmd.finalize_options()`. We want to change this behavior, so we have to consider changing the test. My patch modifies this test case so that it has a proper name and makes sure that `cmd.finalize_options()` obtains a password from stdin. The involvement of stdin makes testing a little complicated. In a proper testing environment, we'd probably spawn a subprocess and provide it with some real stdin data. The distutils upload command test structure seems not to be prepared for this endeavor, so I have decided to temporarily/locally patch sys.stdin, and ensure restoration with a try/finally clause. With A and B in place, all distutils unit tests validate. I used two methods of invocation, for covering the two cases (with and without attached tty): $ nohup python test_distutils.py 21 out.log $ python test_distutils.py -- keywords: +patch Added file: http://bugs.python.org/file38005/issue18454_py27_prompt.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18454 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6634] sys.exit() called from threads other than the main one: undocumented behaviour
Changes by Jan-Philip Gehrcke jgehr...@gmail.com: Added file: http://bugs.python.org/file37988/issue6634_py35.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6634 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6634] sys.exit() called from threads other than the main one: undocumented behaviour
Changes by Jan-Philip Gehrcke jgehr...@gmail.com: Removed file: http://bugs.python.org/file37986/issue6634_py35.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6634 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6634] sys.exit() called from threads other than the main one: undocumented behaviour
Changes by Jan-Philip Gehrcke jgehr...@gmail.com: Removed file: http://bugs.python.org/file19006/thread_sys_exit_test.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6634 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6634] sys.exit() called from threads other than the main one: undocumented behaviour
Jan-Philip Gehrcke added the comment: For Python 3.5, I have attached a patch that - adds relevant test cases to test_threading.py which probe the interpreter's stderr output for compliance with what the docs state. - makes sys.exit(msg) write msg to stderr, even if called from a non-primary thread, so that the tests succeed. If we take this path, the documentation for 3.5 does not need to be adjusted. The discussion in this thread diversified itself a bit: Why don't threads have their own ThreadExit exception, rather than overloading the use, and therefore, the meaning, of the SystemExit exception? sys.exit and the SystemExit exception should *only* be used to exit the entire system, not just a thread! While I absolutely agree that this would be conceptually cleaner, implementing this would be a larger refactoring task. Deciding whether this should be done or not slows this issue down, and I think this discussion should probably be taken elsewhere. -- versions: +Python 3.5 -Python 3.1, Python 3.2 Added file: http://bugs.python.org/file37986/issue6634_py35.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6634 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6634] sys.exit() called from threads other than the main one: undocumented behaviour
Changes by Jan-Philip Gehrcke jgehr...@gmail.com: Removed file: http://bugs.python.org/file37988/issue6634_py35.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6634 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6634] sys.exit() called from threads other than the main one: undocumented behaviour
Changes by Jan-Philip Gehrcke jgehr...@gmail.com: Removed file: http://bugs.python.org/file37983/issue6634_py27.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6634 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6634] sys.exit() called from threads other than the main one: undocumented behaviour
Jan-Philip Gehrcke added the comment: Regarding the documentation patch: I like to start sentences with a capital letter. Perhaps change it to start “Calling :func:`exit` only terminates . . .”. Thanks for feedback. Have now used Invocation of to not repeat call* in the sentence, because I left the when called from the main thread part unchanged. Okay? With the code change patch, it might be neater to use the SystemExit.code attribute rather than e.args[0]. Oh, thanks. Was not aware of the existence of the `code` attribute. If anyone else was wondering: existence and behavior are defined in Objects/exceptions.c via `static PyMemberDef SystemExit_members[]` and via `static int SystemExit_init()`. It is populated upon construction of a SystemExit instance: Py_CLEAR(self-code); if (size == 1) self-code = PyTuple_GET_ITEM(args, 0); else /* size 1 */ self-code = args; Hence, the translation from arguments to exit code considers *all* arguments. I adjusted the patch to use the `code` attribute. -- Added file: http://bugs.python.org/file37989/issue6634_py35.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6634 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6634] sys.exit() called from threads other than the main one: undocumented behaviour
Changes by Jan-Philip Gehrcke jgehr...@gmail.com: Added file: http://bugs.python.org/file37990/issue6634_py27.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6634 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20709] os.utime(path_to_directory): wrong documentation for Windows.
Jan-Philip Gehrcke added the comment: Windows is the only Python-supported platform where utime did not work for directories, ages ago, right? If that is the case, I support Larry Hastings' approach of removing the entire sentence: Whether a directory can be given for path depends on whether the operating system implements directories as files (for example, *Windows does not*) Agreed? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20709 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20709] os.utime(path_to_directory): wrong documentation for Windows.
Changes by Jan-Philip Gehrcke jgehr...@gmail.com: -- keywords: +patch Added file: http://bugs.python.org/file37979/issue20709_py27.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20709 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20709] os.utime(path_to_directory): wrong documentation for Windows.
Changes by Jan-Philip Gehrcke jgehr...@gmail.com: Added file: http://bugs.python.org/file37980/issue20709_tip.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20709 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20709] os.utime(path_to_directory): wrong documentation for Windows.
Jan-Philip Gehrcke added the comment: I have added patches for the documentation, where I removed the sentence in question and re-wrapped the paragraph. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20709 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6634] sys.exit() called from threads other than the main one: undocumented behaviour
Jan-Philip Gehrcke added the comment: For Python 2.7, we will not change behavior, even if unexpected. Instead, the sys.exit-docs should be adjusted and - warn about the fact that nothing is written to stderr if sys.exit(msg) gets called from a non-primary thread, and - note that SystemExit raised in a non-primary thread lets the thread exit silently. I have attached a corresponding patch, please review my wording! -- keywords: +patch Added file: http://bugs.python.org/file37983/issue6634_py27.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6634 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: Running a .py file iteratively at the terminal
On Mon, 26 Jan 2015, varun...@gmail.com wrote: Thanks a lot Mark but that would be a bit trivial. How can I run the same file multiple times? Or if I need to run two commands: srva@hades:~$ python NFV_nw_eu_v3_14_1_15.py --output eu_v3_14_1_15 --demand demands_v3_21_1_15.xml --xml nobel-eu.xml srva@hades:~$ python NFV_v3_7_10_14.py -l log --lp --xml eu_v3_14_1_15.xml repeatedly, how can I do that? Can I write a script to perform this function?If so, can you please help me with it? The first command generates an output file eu_v3 and the second file feeds it to the solver. This is what I intend to do multiple times. I hope I have explained it this time in a much better way. I'm sorry English is my second language and I have some problems in expressing myself at times. Thank You Have you read about Bash shell brace expansion, or a one-liner loop? A simple wrapper script could easily accomplish what you seem to be attempting to do. For more, see: http://tldp.org/LDP/Bash-Beginners-Guide/html/sect_03_04.html http://www.linuxjournal.com/content/bash-brace-expansion http://wiki.bash-hackers.org/syntax/expansion/brace http://tldp.org/LDP/abs/html/loops1.html -- https://mail.python.org/mailman/listinfo/python-list
[issue23039] File name restriction on Windows
New submission from Philip Lee: when using open(filename, 'w') on Windows , File names are not allowed to contain any characters in \/:*?| , however open(filename, 'w') doesn't throw any exceptions when the file name contains these characters . I think some warning should be written in the documentation or exceptions thrown should happen when the file name contains these characters . -- components: IO messages: 232555 nosy: iMath priority: normal severity: normal status: open title: File name restriction on Windows type: enhancement ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23039 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19725] Richer stat object
Philip Jenvey added the comment: I can't find the paper trail of what I originally thought was a consensus or even that many clear pronouncements about it, but I recall Nick being originally opposed to it but he later changed his mind, you can see his approval here: https://mail.python.org/pipermail/python-dev/2013-May/125809.html 'It's also quite likely the rich stat object API will be pursued for 3.5' https://mail.python.org/pipermail/python-dev/2013-November/130582.html https://mail.python.org/pipermail/python-dev/2013-November/130588.html Antoine seems ok w/ it, encouraging others to make it happen: https://mail.python.org/pipermail//python-dev/2013-September/128708.html You can probably find a bit more discussion within those threads -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19725 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20584] On FreeBSD, signal.NSIG is smaller than biggest signal value
Changes by Philip Semanchuk osvens...@users.sourceforge.net: -- nosy: +osvenskan ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20584 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
PyPy3 2.4.0 released
= PyPy3 2.4 - Snow White = We're pleased to announce PyPy3 2.4, which contains significant performance enhancements and bug fixes. You can download the PyPy3 2.4.0 release here: http://pypy.org/download.html PyPy3 Highlights Issues reported with our previous release were fixed after reports from users on our new issue tracker at https://bitbucket.org/pypy/pypy/issues or on IRC at #pypy. Here is a summary of the user-facing PyPy3 specific changes: * Better Windows compatibility, e.g. the nt module functions _getfinalpathname _getfileinformation are now supported (the former is required for the popular pathlib library for example) * Various fsencode PEP 383 related fixes to the posix module (readlink, uname, ttyname and ctermid) and improved locale handling * Switched default binary name os POSIX distributions to 'pypy3' (which symlinks to to 'pypy3.2') * Fixed a couple different crashes related to parsing Python 3 source code Further Highlights (shared w/ PyPy2) Benchmarks improved after internal enhancements in string and bytearray handling, and a major rewrite of the GIL handling. This means that external calls are now a lot faster, especially the CFFI ones. It also means better performance in a lot of corner cases with handling strings or bytearrays. The main bugfix is handling of many socket objects in your program which in the long run used to leak memory. We fixed a memory leak in IO in the sandbox_ code We welcomed more than 12 new contributors, and conducted two Google Summer of Code projects, as well as other student projects not directly related to Summer of Code. * Reduced internal copying of bytearray operations * Tweak the internal structure of StringBuilder to speed up large string handling, which becomes advantageous on large programs at the cost of slightly slower small *benchmark* type programs. * Boost performance of thread-local variables in both unjitted and jitted code, this mostly affects errno handling on linux, which makes external calls faster. * Move to a mixed polling and mutex GIL model that make mutlithreaded jitted code run *much* faster * Optimize errno handling in linux (x86 and x86-64 only) * Remove ctypes pythonapi and ctypes.PyDLL, which never worked on PyPy * Classes in the ast module are now distinct from structures used by the compiler, which simplifies and speeds up translation of our source code to the PyPy binary interpreter * Win32 now links statically to zlib, expat, bzip, and openssl-1.0.1i. No more missing DLLs * Many issues were resolved_ since the 2.3.1 release in June .. _`whats-new`: http://doc.pypy.org/en/latest/whatsnew-2.4.0.html .. _resolved: https://bitbucket.org/pypy/pypy/issues?status=resolved .. _sandbox: http://doc.pypy.org/en/latest/sandbox.html We have further improvements on the way: rpython file handling, numpy linalg compatibility, as well as improved GC and many smaller improvements. Please try it out and let us know what you think. We especially welcome success stories, we know you are using PyPy, please tell us about it! Cheers The PyPy Team -- https://mail.python.org/mailman/listinfo/python-announce-list Support the Python Software Foundation: http://www.python.org/psf/donations/
PyPy3 2.4.0 released
= PyPy3 2.4 - Snow White = We're pleased to announce PyPy3 2.4, which contains significant performance enhancements and bug fixes. You can download the PyPy3 2.4.0 release here: http://pypy.org/download.html PyPy3 Highlights Issues reported with our previous release were fixed after reports from users on our new issue tracker at https://bitbucket.org/pypy/pypy/issues or on IRC at #pypy. Here is a summary of the user-facing PyPy3 specific changes: * Better Windows compatibility, e.g. the nt module functions _getfinalpathname _getfileinformation are now supported (the former is required for the popular pathlib library for example) * Various fsencode PEP 383 related fixes to the posix module (readlink, uname, ttyname and ctermid) and improved locale handling * Switched default binary name os POSIX distributions to 'pypy3' (which symlinks to to 'pypy3.2') * Fixed a couple different crashes related to parsing Python 3 source code Further Highlights (shared w/ PyPy2) Benchmarks improved after internal enhancements in string and bytearray handling, and a major rewrite of the GIL handling. This means that external calls are now a lot faster, especially the CFFI ones. It also means better performance in a lot of corner cases with handling strings or bytearrays. The main bugfix is handling of many socket objects in your program which in the long run used to leak memory. We fixed a memory leak in IO in the sandbox_ code We welcomed more than 12 new contributors, and conducted two Google Summer of Code projects, as well as other student projects not directly related to Summer of Code. * Reduced internal copying of bytearray operations * Tweak the internal structure of StringBuilder to speed up large string handling, which becomes advantageous on large programs at the cost of slightly slower small *benchmark* type programs. * Boost performance of thread-local variables in both unjitted and jitted code, this mostly affects errno handling on linux, which makes external calls faster. * Move to a mixed polling and mutex GIL model that make mutlithreaded jitted code run *much* faster * Optimize errno handling in linux (x86 and x86-64 only) * Remove ctypes pythonapi and ctypes.PyDLL, which never worked on PyPy * Classes in the ast module are now distinct from structures used by the compiler, which simplifies and speeds up translation of our source code to the PyPy binary interpreter * Win32 now links statically to zlib, expat, bzip, and openssl-1.0.1i. No more missing DLLs * Many issues were resolved_ since the 2.3.1 release in June .. _`whats-new`: http://doc.pypy.org/en/latest/whatsnew-2.4.0.html .. _resolved: https://bitbucket.org/pypy/pypy/issues?status=resolved .. _sandbox: http://doc.pypy.org/en/latest/sandbox.html We have further improvements on the way: rpython file handling, numpy linalg compatibility, as well as improved GC and many smaller improvements. Please try it out and let us know what you think. We especially welcome success stories, we know you are using PyPy, please tell us about it! Cheers The PyPy Team -- https://mail.python.org/mailman/listinfo/python-list
Re: Get named groups from a regular expression
On 2014-07-01, Florian Lindner mailingli...@xgm.de wrote: Is there a way I can extract the named groups from a regular expression? e.g. given (?Ptestgrp\d) I want to get something like [testgrp]. The match object has an attribute called groupdict, so you can get the found named groups using match.groupdict.keys. I can't remember what happens to unnamed groups (I prefer to name every group I want), but ISTR that there is a list of capture groups in which the indexes are the capture groups number (i.e. what you'd use to backreference them). Can I make the match object to return default values for named groups, even if no match was produced? A lazy solution I've used was to write a default dict, then update it with the groupdict. I doubt that's all that efficient, but the defaults were constant strings and the program was network-bound anyway. -- https://mail.python.org/mailman/listinfo/python-list
