Re: [Python-Dev] Bytes path support
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/19/2014 01:43 PM, Ben Hoyt wrote: >>>> The official policy is that we want them [support for bytes >>>> paths in stdlib functions] to go away, but reality so far has >>>> not budged. We will continue to hold our breath though. :-) >>> >>> Does that mean that new APIs should explicitly not support bytes? >>> I'm thinking of os.scandir() (PEP 471), which I'm implementing at >>> the moment. I was originally going to make it support bytes so it >>> was compatible with listdir, but maybe that's a bad idea. Bytes >>> paths are essentially broken on Windows. >> >> Bytes paths are "essential" on Unix, though, so I don't think we >> should create new low-level APIs that don't support bytes. > > Fair enough. I don't quite understand, though -- why is the "official > policy" to kill something that's "essential" on *nix? ISTM that the policy is based on a fantasy that "it looks like text to me in my use cases, so therefore it must be text for everyone." Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAlPzj8AACgkQ+gerLs4ltQ6AjACgzSC6kBXssnzNhVTdahWIi48u 5SwAn3+ytO/bh1YrVzCbVJqU/wIs7WiA =qGLR -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Critical bash vulnerability CVE-2014-6271 may affect Python on *n*x and OSX
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/25/2014 08:59 PM, Cameron Simpson wrote: > Your cable/adsl modem? Probably an embedded Linux box, possibly using > bash, and certainly a dhcp client of the ISP. Better still, for many > people that same comprimisable modem is the DHCP _server_ for their > home LAN... Generally those devices are *not* using bash as '/bin/sh': it is too heavyweigh. Most will use 'busybox' or some other Swiss-army command for stuff which is separate commands on a "normal" linux system. Tres. - -- ======= Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAlQkwaAACgkQ+gerLs4ltQ4mYwCguMEUfwXZTM4FRS80HPCZx8DY hogAoNVIjWfn1R2obPH9LhRGFkzBR4Pw =oXxP -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Status of C compilers for Python on Windows
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/10/2014 05:26 AM, Larry Hastings wrote: > IMO the benefit from supporting other compilers on Windows is > negligible Did you miss the OP's point that OpenBLAS cannot be compiled with MSVC, raising the priority of mingw-buildable extensions for numerical work? Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAlQ37vYACgkQ+gerLs4ltQ6V9ACffcq9Cn+kHzDZxaWJ63NVb6Uk SasAoK5kNfBrCupcBz3FcRsUjs2aZxvu =LFqg -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Status of C compilers for Python on Windows
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/28/2014 11:59 PM, Stephen J. Turnbull wrote: > most developers on Windows do have access to Microsoft tool I assume you mean python-dev folks who work on Windows: it is certainly not true for the vast majority of develoeprs who use Python on Windows, who don't have the toolchain build their own C extensions. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAlRQ+BYACgkQ+gerLs4ltQ7L8QCeJ4NYs+//39O0dUUNqG1lXy1Z 7GMAniUCjmodCfKAVBF/yeOv3GrR03Fm =n4bm -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Status of C compilers for Python on Windows
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/29/2014 10:31 AM, R. David Murray wrote: > If you are writing code targeted for Windows, I think you are very > likely to have an MSDN subscription of some sort if your package > includes C code. I'm sure it's not 100%, though. My experience with distributing distributions-with-extensions indicates that the vast majority of Windows developers who are "downstream" users for those distributions *cannot* build them from source: if there is no MSI / bdist_win (maybe now wheel), they won't use the project. (Note that "having an MSDN subscription" is not the same as "knowing how to configure which compiler such that it can bulid extensions against an installed Python binary"). Tres. - -- ======= Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAlRRAskACgkQ+gerLs4ltQ7ILQCfbFCmgZqH+mZa28bQwjNuZruK 6BcAoLG/fxhi4LBkAgZoXNaxq6gi+Pbx =8OvV -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/02/2014 11:50 AM, Brett Cannon wrote: > So do people want PEPs or experimentation first? I'd vote for experimentation, to ground the discussion in actual practice. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAlR99X8ACgkQ+gerLs4ltQ7dpACgsGq7Rii7seJXHCOVMUymbOdL 2KQAn3qcOGWynKU4rd/H39hpBxwSsbk9 =93kJ -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Overriding stdlib http package
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/14/2015 11:54 AM, Antoine Pitrou wrote: > On Wed, 14 Jan 2015 08:32:23 -0800 Demian Brecht > wrote: >> Hi all, >> >> As part of the work I'm doing on httplib3 (now that I've actually >> gotten a bit of time), one of the things I'm trying to get done is >> injection of httplib3 over http in order to not have to modify all >> import paths in modules and such. Here's the gist of what I have so >> far: https://gist.github.com/demianbrecht/bc6530a40718e4fcbf90. > > What don't you simply monkeypatch sys.modules, e.g.: > > import myhttplib > > sys.modules['http'] = myhttplib > > or doesn't it work as desired? Doesn't that leave any prior imports broken (using the original module)? Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAlS2oZYACgkQ+gerLs4ltQ457gCfTSuwfOUHOivoQAUncq6VbxdQ YOkAoLec1hghar8IULuaz5W0MTXOtQm/ =tvv7 -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Any grammar experts?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/26/2015 09:43 AM, Barry Warsaw wrote: > This is head-scratcher code that I'm sure I'd get asked about from > folks who aren't steeped in all the dark corners of Python. I don't > know if that's an argument not to adopt the PEP, but it I think it > would be a good reason to recommend against using such obscure syntax, > unless there's a good reason Heh, 2003 called, and they want their "list incomprehension" debate back. ;) Tres. - -- ======= Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAlTGoNcACgkQ+gerLs4ltQ4AWQCfQ/zjosbaC6YcPItzmxZer/oW f/cAoLwXzzfHV2LhT4AZD/KS31TkKJyI =Oxqm -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Allow annotations using basic types in the stdlib?
On 11/06/2017 01:25 PM, R. David Murray wrote: > Maybe I'm being a curmudgeon standing in the way of progress, but I'm > pretty sure there are a number of people in my camp :) I'm definitely there: anything which optimizes machine-readabilty over readability for the Mark 1 eyeball is a lose. Tres. -- ======= Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [python-committers] Enabling depreciation warnings feature code cutoff
On 11/09/2017 01:49 AM, Greg Ewing wrote: >> On 8 November 2017 at 19:21, Antoine Pitrou wrote: >>> The idea that __main__ scripts should >>> get special treatment here is entirely gratuitous. > > When I'm writing an app in Python, very often my __main__ is > just a stub that imports the actual functionality from another > module to get the benefits of a pyc. So enabling deprecation > warnings for __main__ only wouldn't result in me seeing any > more warnings. IIUC, that would be as expected: you would see the warnings when running your test suite exercising that imported code (which should run with all warnings enabled), but not when running the app. Seems like a reasonable choice to me. Tres. -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Tricky way of of creating a generator via a comprehension expression
On 11/22/2017 07:00 PM, Yury Selivanov wrote: > I wouldn't say that it's obvious to anyone... > > I think this thread has started to discuss the use of 'yield' > expression in comprehensions, and the outcome of the discussion is > that everyone thinks that we should deprecate that syntax in 3.7, > remove in 3.8. Let's start with that? :) You guys are no fun: such a change would remove at least one evil "bwah-ha-ha" cackle from David Beazley's next PyCon talk. :) Tres. -- ======= Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] What's the status of PEP 505: None-aware operators?
On 11/29/2017 01:02 PM, Barry Warsaw wrote: > I don’t know whether I like any of this but I think a more > natural spelling would be: > > val = name.strip()[4:].upper() except (AttributeError, KeyError) as -1 > > which could devolve into: > > val = name.strip()[4:].upper() except KeyError as -1 > > or: > > val = name.strip()[4:].upper() except KeyError # Implicit `as None` Of all the proposed spellings for the idea, this one feels most "normal" to me, too (I'm -0 on the idea as a whole). > I would *not* add any spelling for an explicit bare-except equivalent. > You would have to write: > > val = name.strip()[4:].upper() except Exception as -1 Wouldn't that really need to be this instead, for a true 'except:' equivalence: val = name.strip()[4:].upper() except BaseException as -1 Tres. -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Is it useful to update cgitb module?
On 04/08/2018 12:45 AM, Alex Walters wrote:
> Are there people still actively developing new cgi scripts in python?
In addition to the "magic" support triggered by 'cgitb.enable()', the
module also exposes useful utility functions ('cgitb.html()' and
'cgitb.text()') which are used by non-CGI third-party libraries to render
tracebacks for debugging purposes. Enhancing those methods seems pretty
reasonable to me.
Tres.
--
=======
Tres Seaver +1 540-429-0999 tsea...@palladion.com
Palladion Software "Excellence by Design"http://palladion.com
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] (name := expression) doesn't fit the narrative of PEP 20
On 04/27/2018 05:11 PM, Tim Peters wrote: > In this specific case, line-oriented coverage tools have missed > accounting for all possible code paths since day #1; e.g., > > x = f() or g() > > You don't need to reply to messages so obviously irrelevant to the PEP > unless you want to. It's not like Guido will read them and go "oh! a > binding expression in a ternary conditional is a fundamentally new > potential problem for a line-oriented coverage tool! that's fatal" ;-) FWIW, Ned Batchelder's 'coverage.py' does a good job with branch coverage. I haven't seen anything in this discussion which indicates that binding expressions will change that at all. Tres. -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 572: A backward step in readability
On 04/30/2018 12:37 PM, Steven D'Aprano wrote: > - comprehensions? not readable, easy to abuse, hard for beginners > to comprehend; I still refer to them as "list incomprehensions" in my head, particularly for those whic expand across line breaks. Tres. -- ======= Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Status on PEP-431 Timezones
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/27/2015 02:04 AM, Tim Peters wrote: > The naive arithmetic within a timezone is already correct, by its own > internal criteria. It's also useful (see the original discussions, > or Paul Moore's recent brief account). "Naive" alarm clocks (those which don't know from timezones) break human expectations twice a year, because their users have to be awake to fix them (or make the clock itself out-of-whack with real civil time for the hours between fixing and the actual transition). For confirmatoin, ask your local priest / pastor about the twice yearly mixups among congregants whose clocks don't self-adjust for the DST boundary: some show up late / early for church *every* time the local zone changes. I'd be in favor of dropping "days" from timedelta, myself, for just this reason: if "1 day" is the same for your usecase as "24 hours", then just do the math yourself. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBAgAGBQJVtqPcAAoJEPKpaDSJE9HY4oEP+wUSWTeQS7cn3FLVBOeUV/lZ MIqZSnIGYOaSS6JDo2oTjm+yQWySEp5QMXHNYohPOkkkYDdu8L/r250KKb6F3fbo OMnNXlBCVHi66kFCs0x3+zQIlhSzkYV2FcT39gNu0llw5gODtmbbvYZE+CA4ej6R PIhnizyT7bXa+q2WYBrL0/+w/IBuv4H3d/x0b79cPZpqRZeI57k90qsee9SSPyDb MGs76IUOfJuZNruqfuY+zhFlfwB5kOt8U4kTlXZS4At1TKskoH5zuIiaHZooN6gy fBz3Zzt2XKYiWPWrzEbVeXrdXmAFRyr5sWqVQ0SliKA06rq1Tr5h53orGLidMaPe noUnz8YQHssY5e/kAbSUv6C93GNbldNEFOV1Ab03JT+NPrhNxPqi1ZGTJsMDc+Tl HI2I5C1TXW8ZPx/US2+Zt0yu0HX82EX03UPlRW4wZZSyKw7eCosF9fWXwufF9yTP 9v0otEB/x3rN1TJgc+7U4r1JmYPy+eYyjKs1xy58kb/a7awSvlmEeWvQelGqQKc+ lnRT6VxzVlgmTginq/5oHyFkI5OFTYuukuQDZx3ocd1g7EX42pNRYHVcMbZiQ9L5 DFKrENQDkegTkX+g1BUlVSW67smrFfki6Y7O/5R378x+q/sn6oqYe9334C+ccbz8 8jA16niF9EiwaxieLH9w =I31e -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Status on PEP-431 Timezones
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/27/2015 06:03 PM, Tim Peters wrote: > Even if days weren't a distinguished unit for timedelta, I'd still > much rather write, e.g., > > timedelta(days=5, hours=3) > > than > > timedelta(hours=123) > > or > > timedelta(hours=5*24 + 3) > > etc. The intent of the first spelling is obvious at a glance. - From a human's perspective, "a day from now" is always potentially unambigous, just like "a month from now" or "a year from now", whereas "24 hours from now" is never so. In a given application, a user who doesn't care can always write a helper function to generate hours; in an applicatino whose developer who *does* care, the 'days' argument to timedelta in its current does *not* help achieve her goal: it is an attractive nuisance she will have to learn to avoid. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBAgAGBQJVttPGAAoJEPKpaDSJE9HY0N4QAMQ+Q1/m6Dgg97aS1fRFrMA1 gi7lrWEuW0II0V9bOvB+j0IkASBahreauYb+MBnXXSy1JEDRpVQX7h4SHzLMQ+TF YSKnxCCY1UktpegkriZF7FoN8Rhv3egA01qWPO0RjHUkZym7/W2zN5cXhRTeij8N dbAcoT5y4gdii55T+edWjYNJDFihgKNEuh2KMPmMH37tYqOKCFsz1ojX2ox7e4dC 2yEACVz8G+bmUQQ/WXRKsM4pvMf616U9qkMcEYCVzqV+4smX+/z6c7gs244UVcr4 b4m6Du6UTNAtZpSkToYZvN9R2WbDmbG4FnUrF9eso7m1S2BjdlNyxJS7zGmp+Ttj XxmPeptC/INx8EaILYlB70gDDVztU+QBeolP9lfmfpY3srhI1a2uIGH2LhhOuy+F xcRoGaOIg3+JFyPa8ye6OAg6Vka9h+e02ZWaAAxfRhZgnnNduUnTaomuTKi8sCAa s3AHG4E5dOTJdLGxhgVEOSl9nqIJNmVxLxxb2utcS7W5G28KHYLzgV6w2r/fOkYf FvN5Lj6qQuQTPKdN807/7cl1fqOGPg4P74GMojVA816aNtjh4hTw/2AXqZ0Q0LTq QzhatRaDY+cu1SSZV9aDuCxvm4chjITucb6g7/dvR1xSY4Y+oxFgt3/KO2N5jJSY jBlJGbgGp9kukkwO2ret =Aw0Q -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Status on PEP-431 Timezones
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/27/2015 06:11 PM, Ronald Oussoren wrote: > Treating time as UTC with conversions at the application edge might > be "cleaner" in some sense, but can make code harder to read for > application domain experts. > > It might be nice to have time zone aware datetime objects with the > right(TM) semantics, but those can and should not replace the naive > objects we know and love. Interesting. My experience is exactly the opposite: the datetimes which "application domain experts" cared about *always* needed to be non-naive (zone captured explicitly or from the user's machine and converted to UTC/GMT for storage). As with encoded bytes, allowing a naive instance inside the borders the system was always a time-bomb bug (stuff would blow up at a point far removed from which it was introduced). The instances which could have safely been naive were all logging-related, where the zone was implied by the system's timezone (nearly always UTC). I guess the difference is that I'm usually writing apps whose users can't be presumed to be in any one timezone. Even in those cases, having the logged datetimes be incomparable to user-facing ones would make them less useful. Tres. - -- ======= Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBAgAGBQJVttcdAAoJEPKpaDSJE9HYSlEP/0b7A9swT3m0uImdmzSZNJCW EShQuxkclKlADP0Qqvshbiew1lsdqSPTZQ5QOUnqxeo+F0C1pCSABgFmXA3Jjzon lxbwOGFFDhBburJ/F5zAO3XnawvL2p/M4dV+3Zea2inO0X+iNUuHvNjwx/e/qR4i XdC8IyyJZtsFFL+l5KAv7xOT6SaCOB7OrVTZySHrhmfeziClzeBC8GWI00zYIQjj BYQJB+lLhSBdb3b4u2fqhGtbrFtTHDDHEPC/mWdWAvzJN98YaeOtiTOAqiIg5Xai TssJwAvonxOy5P8f5XdW03kbaKqmslWVk/0xIT7svjJnfPXVFzHoFJZZAJMEt34s uZXu79g5ype8gyIJceXZV9/iS6GKHhfUlNTRvemJZb1aiq1QJ26otv2n97yqFbdo PYfbjSU5EhK7h42138QYCM1JmKmIEIBbb+RN5O5ZaJqWEs1IstaMI1K7rM/Gt9dj +Du0wV85Vi0ydgrZ2w8z2ZCL3bnl5wW7y8mBiSNWx1OEK7zRn/tq7/+nd9bFi1L0 8KIY8xJn5t0SU+5BSpisxTSAdX8JD6bAPy3wZlNDP8FFfB9zUyCrhRE58cDsvPdO BQYteyWrpGQJxf2i5UQTLruW2JK3i1lL0en4spucQnBI/eHs7VVHMbfpOpdXhcIl TR7c9fNwV0kn7EggTajx =nRMI -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Status on PEP-431 Timezones
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/27/2015 09:36 PM, Tim Peters wrote: > So what do _you_ do with datetime arithmetic, Tres? Do you do > datetime calculations at all, or just store/retrieve values as-is? > If the former, are you disturbed that adding timedelta(hours=24) to > an aware datetime object never changes the time components (only the > day, and possibly also month, and possibly also year)? If that has > disturbed you, did you find a way to accomplish what you wanted > instead - or are you still stuck? ;-) Sample use cases: - - Embargo a pre-prepared story until 8:00 AM US/Central next Monday. - - Likewise, but allow it to run for three weeks. - - Create a recurring event which occurs from 7:00 - 9:00 PM US/Eastern on the last Thursday of each month. - - Issue a bid for a commodity lot N days before its expiration date; update that bid (if another bid has occurred) at the same time each day until expiration. - - Mark messages published on a distributed event channel to allow clients to sequence them unambiguously. - - For a given sequence of events: if no subsequent matching event occurs within five calendar days of the last event in the sequence, issue a "resolved" event, terminating the sequence. - - The same, except define the interval using "business days" (including applying a user-defined holiday calendar). - - Measure / bucket widgets produced across multiple production lines by quarter / month / day / shift / hour, and generate reports comparing results week-over-week, quarter-over-quarter, etc. In none of those cases involving "days" was the "one day is 24 hours, exactly" a sufficient approximation, and none of them could tolerate naive datetimes. Typically, the application used a "date interval" object (or a recurrence object) which generated date offsets without assuming that a "day" was 86400 seconds. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBAgAGBQJVt3ArAAoJEPKpaDSJE9HYfCcP/07RNZY6Vp5wfcR8wnv3Zk/Z 3SgaEWPIG7s8ysqUhcxT/E6pMdgrLDwSm681Ceh8SDFKdvmXIgSO4UXdsHz6X9Ja gffUk1p5m/A1p0GFdcIMN9EHI1Ligtrf/s0gYJ+b0TqiDUW9mpD1xOmQaNK2/eE4 xf3iYSdFgvcqNMlIzQ+AyzP53M9npv78zCqr/LI18mRczMOHENb98jXeWycIMHyV TbHL/cZ///Uj1IqAmydezj4K0biPwUeMsNeqzzuMbDsiVFdZn+rql9N+V4BuzINZ ivmvdEIFdBqFoRcJJyoWsuqaR8GX0i/2LTVgj4Xcustj1Wnh2Aq+2yUNi0DQvjxh Y79QbVPtPyjkzFUh/dZG5hLSAEWxXtbaFsinq1eN+hraBXHAN4sTdUeL1zGV7Pz5 SSQXwe2cabqALzjbpSiLN8gZ3s7DbcVn4uDLsS3L7iyoC5Y51puZut6ui+TmdbgK fG2zvkRNayOyiRa1vymNZsjiM9XYrNABVhuVdM+xgqCe62q+bcUKKVKRIZY1JWq4 Fh0hy9MVPeT51oFuaIAPQJfPKleSLf8xElHZ9M0Gm4PbJDvmr04AjZ7MHWicXsqR pbhlbfIDO8c2Pt7JfjLPGY/0UZi0ZVeJV8bD5EaM3xcn80DLKW9UL+8Yg4h9br59 RURP7/N6S66jAEHfcUFo =3LBp -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] async/await behavior on multiple calls
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/16/2015 01:11 AM, Nick Coghlan wrote: > One smaller step that may be helpful is changing the titles of a > couple of the sections from: > > * 18.5.4. Transports and protocols (low-level API) * 18.5.5. Streams > (high-level API) > > to: > > * 18.5.4. Transports and protocols (callback based API) * 18.5.5. > Streams (coroutine based API) > > That's based on a sample size of one though (a friend for whom light > dawned once I explained that low-level=callbacks and > high-level=coroutines), which is why I hadn't written a patch for it. +1. That certainly tripped the switch for me. I wish more of the asyncio stuff would illuminate itself so smoothly. ;) Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBAgAGBQJWcbN/AAoJEPKpaDSJE9HYbyUQAJIzzMz7ksUucMZWyF5PvSyg r0Y1ULmGeLxXloR1hw26ToKQe4EvcgUXU39sIE2Ck7HyDtNHl8CorMyd0aVkcjKW zFODj0DsEvphlQk+vQPnZZhWxb8xuKlsWmr2PqSZdVRlGK+xkaraSzJsa+loI70/ Vw8FipfS1ytpq1qlI3i8h4UWZLg+CPsa96Lgwz+GW+TmYawYHjzCr/NNhlT6UnsA JoGxRLZpNOgYeS6/Xo7p2gBOz8MZxE3e7UNeHmE2H96aIz7n6E6A3EKsJ2ms9kWy cjuMJ21N+SmSODXfBxovfiTOE0QJ+GAqRc26vWWjbYqTrtmPrg8F7tCrGZlpILsK sYNJvUAzWCgOhG3eI/SJ8NHVdfuPszPdDVZvm2jk0om2UKMjXKmoxago5aW7Ijb7 T9sLLVUWuvxx/54QkJEaFdLYwmEK2DnyVdNvPf7xrMNtKfXrsmFxxtnSjN3pSkuK tucucR7VVlM2Bm1uxwB7Oqqks44lthEU0LNWNiurujOFX8sUpgIy9rSPntv/7mnK f44v43Rmshshc3SrPAJuzafpAG4kPrM2J6PTF4OSNwg5ZYj8hlMPI6vIdsrX/q7U iJKbyYkHAY09yjYOASmTYUXTS/2gyjMG6uKgIabBuQmVhWR63ezlq1D17aCHCVBG hM0dlyReGudfk/0jM6NW =II0x -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Challenge: Please break this! (a.k.a restricted mode revisited)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/10/2016 06:31 PM, Jon Ribbens wrote: > Unless someone knows a way to get to an object's __dict__ or its type > without using vars() or type() or underscore attributes... Hmm, 'classmethod'-wrapped functions get passed the type. Tres. - -- ======= Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBAgAGBQJXCwKgAAoJEPKpaDSJE9HYHbAP/ibVrlKBTqkwePFr4n4hfA5Z 6te+FCzYm4RfAiIMq0Mitc9mFzeeAx5J9Z6kxONkbCBoBbhttcngR1uHWHHR/7tk a9OVKCu0fzvQvKM9J1wPWdu6uB50TZ2PmRiZ1nChXG2XKC8F3xnj/JwZod0N+3vK zus1T6/5vB6pm+q/hm9gh1yd9gTRldzoVQ9T2Tp8vo6PiYxe5qBwfhIHKR8xtWVs eUG0OR1w8QzaU97NDTOShotDq9Ekow66zqlhppqUGSmt2nOTDndLekse6q1l/oir nMuPBxgyb/CkQ9+KNXb3UvT5l8MLmCtJaMm/To0n8OUBSXG8sspP0oUSiMLUXc5a F/haZnpD2jLmCFz9ivBxIpFRVkLIajwovzLLItSzePclZHj6TChctSQvGPY0roVD BYVnGa4i7vi46mSzkeWvXKT2XFed2pCklD+FLnS6RnShxaxj1VEct8LVAJHFNAJ4 qg1dyLlTeclWUdoerRdGG2J7oa3Ib04ydh9OxnB1Y5KGa5iDCmfydHw24BU0gzvu DIX8tEpq5XSqzN5QAkIbtIV5nyqFwPj1Jun275ETkESTvI0fdja/8RJvJ5npYZj0 yJ5Gc5iXwQWazF18ALFYdyeV+ZKKv2Q5UiYEOBxG02XYaH8GZypAqMbf5apJKQAj PXHMjfW/YIuASrzcporx =1Wrb -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] The pysandbox project is broken
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/13/2013 01:54 AM, Nick Coghlan wrote: > I actually applaud his decision to post his final conclusion to the > list, even though it wasn't the outcome he was hoping for. Negative > data is still data :) Amen! I also applaud the work he put into the idea. Tres. - -- ======= Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlKDmQ0ACgkQ+gerLs4ltQ5XkACgn8riIUhp624gmVxSDqp6KNK+ A74An0Z3BKtc8CU0fSTsr4U76MTMw3Hi =YtJz -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] unicode Exception messages in py2.7
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/14/2013 04:02 PM, Benjamin Peterson wrote: > 2013/11/14 Chris Barker : >> So a proposal: >> >> Use 'replace" mode for the encoding to the default, and at least >> the user would see SOMETHING of the message. In a common case, it >> would be a lot of ascii, and in the worse case it would be a lot of >> question marks -- still better than a totally blank message. >> >> Another option would be to use the str(repr(the_message)) so the >> user would get the escaped version. Though I think that would be >> more ugly. > > Unfortunately both of these things change behavior so cannot be > changed in Python 2.7. Fixing any bug is "changing behavior"; 2.7 is not frozen for bugfixes. The real question is whether third-party code will break when the now-empty error messages appear with '?' littered through them? About the only things I can think of which might break would be doctests, but people *expect* those to break across third-dot releases of Python (one reason why I hate them). Exception repr is explicitly *not* part of any backward-compatibility guarantees in Python. Or code which explicitly works around the breakage could fail (urlparse changes between 2.7.3 and 2.7.4, anyone?d( Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlKFRscACgkQ+gerLs4ltQ6JIgCgvNxHugjjbR3L1crSDK0QJiLb LSYAn2cJnZ8almcfCmWHKhOnCP69bpB3 =MIFq -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Backward-incompatible change to random.randrange in 2.7.6
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 http://hg.python.org/cpython/rev/b1e94e332ec8 Do we really want to change an undocumented-but-effectively-public API in a late-in-the-release-cycle third dot release? It caused, ZODB's tests to fail, for instance. While the docstring said, "Don't use the 'int', 'default', and 'maxwidth' arguments", their names were not intrinsically private. In particular, passing in the 'int' argument was a strategy for generating compatible long values when straddling Python 2.x / Python 3.x. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlKwlXAACgkQ+gerLs4ltQ60DQCgzlO8mHMXQ0vsHNpS9GKwjpmD G6oAoMIjtrKkGTlFj0b9Tfdj5BCu1rYS =GxuS -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Backward-incompatible change to random.randrange in 2.7.6
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/17/2013 01:40 PM, Guido van Rossum wrote: > This really seems a case of ZODB depending on internals where it > really, really should have known better. Calling this "a de-facto > public interface" seems way too far a stretch of the intention. And > please don't fix it by version-testing and using a different argument > name... The usage is *ancient*: Jeremy checked it in 2001-10-05: https://github.com/zopefoundation/ZODB/commit/fd1653580ca67bdc281fb8c54662c97dd3cf1aaa The comment about "do not pass the 'int' or 'default' arguments" goes back to at least the 'whrandom.py' module in 1.5.2. ;) Tres. - -- ======= Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlKwn7QACgkQ+gerLs4ltQ4WzACeOMXqg5Jg8ck3vK3cCDuTgKSS 8GwAn0yR8ukdQTh5Wo0jGDHq/AIgu+Yg =fTUf -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Changing Clinic's output
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/07/2014 02:53 PM, Antoine Pitrou wrote: > - prefix all Clinic-generated lines with a recognizable marker, e.g. > "/* AC */" +1. I would wrap generated code in even-more-visually-distinct markers, both before and after, e.g.:: /* - Begin ArgumentClinic */ /* - End ArgumentClinic -- */ I think delineating gencode blocks this way makes it easier to ignore them (or find them, if needed). Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlLMcssACgkQ+gerLs4ltQ5dSACfSEpN2E1EU/AAJhOiaQr1TKgg jZAAn2Wok6cr1suhwOfEgFZmqlsJ6HB8 =AT9/ -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 460: allowing %d and %f and mojibake
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/15/2014 12:57 AM, Stephen J. Turnbull wrote: > asciistr *canonizes* something as an ASCII string, and therefore > compatible with both bytes and str. It can't *create* such a thing > ex nihilo. How many miracles must be attested? Tres. - -- ======= Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlLWJbYACgkQ+gerLs4ltQ7RHACfft2ysdHiE9zJM72ycqi0Uqyl s5EAnR9Z21tgqsFVsPUEPiWgtXNxCWF4 =Thyi -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] AC Derby and accepting None for optional positional arguments
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/16/2014 12:32 AM, Larry Hastings wrote: > We could add a special value, let's call it sys.NULL, whose specific > semantics are "turns into NULL when passed into builtins". This would > solve the problem but it's really, really awful. That doesn't smell too bad too me -- I would prefer to be able to build up all such calls programmatically for testing purposes (e.g., to ensure identical semantics for all code paths between a Python reference implementation and a C extension). Tres. - -- ======= Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlLYNVMACgkQ+gerLs4ltQ79NwCgy3231to9rnw/8I+52hFJE+2w Z9QAnR0pAMfkofhT82K1yQctm0E8TF7j =QaC4 -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] AC Derby and accepting None for optional positional arguments
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/16/2014 04:08 PM, Ryan Smith-Roberts wrote: > [L]et us return to my original example, getservbyname(). Its current > signature: > > socket.getservbyname(servicename[, protocolname]) > > This is not an inspectable signature, since pure Python does not > support bracketed arguments. To make it inspectable, we must give > protocolname a (valid Python) default value: > > socket.getservbyname(servicename, protocolname=None) > > Unfortunately, while useful and inspectable, this signature is not > correct. For a pure Python function, passing None for protocolname is > the same as omitting it. However, if you pass None to getservbyname(), > it raises a TypeError. So, we have these three options: > > 1) Don't give getservbyname() an inspectable signature. 2) Lie to the > user about the acceptability of None. 3) Alter the semantics of > getservbyname() to treat None as equivalent to omitting protocolname. > > Obviously #2 is out. My question: is #3 ever acceptable? It's a real > change, as it breaks any code that relies on the TypeError exception. +1 for #3, especially in a new "major" release (w/ sufficient documentation of the change). Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlLYWU8ACgkQ+gerLs4ltQ6obQCglHmIM4kcNOQte7jj9NjL6Xia KQwAn2ircAlSR6iwFIAt6PDz0bs6iIDt =G+GC -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Argument Clinic: what to do with builtins with non-standard signatures?
position, the function yields 0 > times. If "times" is <0, and was supplied via keyword, the function > yields infinitely-many times.) > > Solution: 0) Do nothing, don't convert the function. 1) Change the > signature until it is Python compatible. This new signature *must* > accept a superset of the arguments accepted by the existing signature. > (This is being discussed right now in issue #19145.) I can't imagine justifying such an API design in the first place, but sometimes things "jest grew", rather than being designed. I'm in favor of # 1, in any case. If real backward compatibility is not feasible for some reason, then I would favor the following: 2) Deprecate the manky builtin, and leave it unconverted for AC; then add a new builtin with a sane signature, and re-implement the deprecated version as an impedance-matching shim over the new one. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEUEARECAAYFAlLikGgACgkQ+gerLs4ltQ5UEgCYu13+7HfmwWw2hq7GrsBGM4I3 UACgz3WKVvqG1QkOsx8C3tiCjp5PkL0= =2tLW -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Quick poll: should help() show bound arguments?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/24/2014 11:07 PM, Larry Hastings wrote: > A) pydoc and help() should not show bound parameters in the signature, > like inspect.signature. B) pydoc and help() should show bound > parameters in the signature, like inspect.getfullargspec. +1 for A: it is how you would actually call the object on which 'help()' is being called. The fact that self will be passed silently is irrelevant to the caller. Tres. - -- ======= Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlLjU4UACgkQ+gerLs4ltQ48SQCg0zMZseKV3EZ/0pRkc5ngt2tb aFMAn0Vhze2wMEim6Vf7F1fvlh+j3PJ/ =Mx/i -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] BugFix for "time" native module in Python 2.7
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/03/2014 02:41 PM, ?? ? wrote: > Hi, guys! > > I have found a bug in module "time" function "sleep" in Python 2.7 > under Windows XP / Server 2003 and lower. I fix this bug locally. But > how could I send you hg patch or pull request or, maybe, commit to > sandbox? > > P.S.: Sorry for my English :-) Create an issue on the Python tracker: http://bugs.python.org/ and attach your patch there. See the Python Developers' Guide for more details: http://docs.python.org/devguide/ Tres. - -- ======= Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlLv9dAACgkQ+gerLs4ltQ6JdQCfbQ5lFmW9OQceVZJFW8Zs3fIz 0m4An3ttIZbdWtVLtOtloMfsrnW4nanE =Cd+P -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython: whatsnew: 'U' mode deprecation (#15204).
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/10/2014 09:09 AM, Nick Coghlan wrote: > Don't we still need U when writing 2/3 compatible code at this point? io.TextIOWrapper was already the superior strategy for anyone straddling Python 2.6+ - Py3k. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlMd56sACgkQ+gerLs4ltQ4+kQCgm2a0KDP/aGTCZD9eUdImjBC2 ny4AoLmyLOlBZOksvu3nwKawo6BTG0Ab =H7l+ -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 4: don't remove anything, don't break backward compatibility
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/10/2014 12:49 PM, Brett Cannon wrote: > I think it got lost in email threading, but Barry pointed out that > Guido famously hates double digit version numbers (as do I, probably > partially because he does after all these years =). "Guido hates them" isn't an argument: its a ukase. Version numbers are tuples, not decimal fractions. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlMd78wACgkQ+gerLs4ltQ4s/ACdEkOvaYjP2d9IZ4g8bVJC/OZl h8gAoIu0IY1qYAhvZQzEo9Up9swJnZ60 =7tsf -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 4: don't remove anything, don't break backward compatibility
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/10/2014 02:50 PM, Paul Moore wrote: > I have seen a number of postings recently pointing to things as "not > until Python 4000" or "not until Python 4.0" (yours was not one that > I noticed, actually, this is a more general point). > > I do think it's a bad idea to start talking in terms of "the next big > compatibility break", even if *we* know there's no immediate plan. > People are very quick to pick up messages like "Now that Python 3 is > out of the way, the Python devs are talking about Python 4" which is > not a message we want to see getting traction. Exactly. If we can't do things sensibly / incrementally without learning from the painful lessons of the past eight years, we ought to give up on the prospect of doing language design altogether. > I'm neither averse to, nor in favour of, a Python 4 compatibility > break in due course I am. I don't think the community can stand another such break. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlMeHRsACgkQ+gerLs4ltQ4p0QCeLWgr2/qOSHmRBLLD+Wz0/+k/ EcwAn2p4lXARRCEYhyqsDpwhq/SrVEak =ZpwN -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Requesting pronouncement on PEP 463: Exception-catching expressions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/12/2014 04:49 PM, Chris Angelico wrote: > You can use hasattr() in place of AttributeError I use: getattr(subject, attrname, default)? *all the time*. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlMg060ACgkQ+gerLs4ltQ70IgCgi2HFt1DRWHaeIlwgjyf1UJiR 1uEAn0+pf2fS+USmesmXtV9O63jA93hq =fLq7 -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] default hg.python.org/cpython is now 3.5
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/17/2014 11:18 AM, Benjamin Peterson wrote: > > > On Mon, Mar 17, 2014, at 7:10, Brett Cannon wrote: >> On Mon, Mar 17, 2014 at 4:51 AM, Victor Stinner >> wrote: >> >>> Until when should we fix bugs in the branch 3.3? Branches 3.1 and >>> 3.2 only accept security fixes, right? >>> >> >> Typically we do one last release before shutting the last bugfix >> branch down, but that's Georg's call since 3.3.5 was released so >> recently. > > Given that, I propose 3.3 goes into security fix mode immediately. Shouldn't we at least do a review of the open issues against 3.3 first, particularly those with patches? E.g. "critcal" / "patch review": http://bugs.python.org/issue?%40search_text=&ignore=file%3Acontent&title=&%40columns=title&id=&%40columns=id&stage=4&creation=&creator=&activity=&%40columns=activity&%40sort=activity&actor=&nosy=&type=&components=&versions=17&dependencies=&assignee=&keywords=&priority=2&%40group=priority&status=1&%40columns=status&resolution=&nosy_count=&message_count=&%40pagesize=50&%40startwith=0&%40action=search or "high" / "patch review": http://bugs.python.org/issue?%40search_text=&ignore=file%3Acontent&title=&%40columns=title&id=&%40columns=id&stage=4&creation=&creator=&activity=&%40columns=activity&%40sort=activity&actor=&nosy=&type=&components=&versions=17&dependencies=&assignee=&keywords=&priority=3&%40group=priority&status=1&%40columns=status&resolution=&nosy_count=&message_count=&%40pagesize=50&%40startwith=0&%40action=search (OT: man does that cry out for a URL shortener built in). Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlMnGFYACgkQ+gerLs4ltQ5o5QCg2YUAmIm5POUXv40VB3DEtJPV cDMAnR9kjBJV0FaGTYrK9beA0YSDKLhQ =4yP2 -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Intricacies of calling __eq__
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/18/2014 07:18 AM, Steven D'Aprano wrote: > Nevertheless, an __eq__ with side-effects is legal Python and may in > fact be useful. E.g., for an LRU usecase. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlMoobQACgkQ+gerLs4ltQ62agCaA6Z++yLV6VkJ5VUu8Q38AP2N TfcAnjWyYE6/taksZQ0J3igJfv9+KhiK =/D19 -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 466: Proposed policy change for handling network security enhancements
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/22/2014 05:11 PM, Nick Coghlan wrote: > In addition to any other module specific contents, this section MUST > enumerate key security enhancements and fixes (with CVE identifiers > where applicable), and the Incomplete sentence. Tres. - -- ======= Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlMuBosACgkQ+gerLs4ltQ74ngCfS7MLZHtVfS7f6x+9mnOIsp+c +CUAoIc5rFIuNJvMephnlAuPhkPXZspy =N8Xk -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Status of PEP 3145 - Asynchronous I/O for subprocess.popen
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/27/2014 09:16 PM, Josiah Carlson wrote: > But here's the thing: I can build enough using asyncio in 30-40 lines > of Python to offer something like the above API. The problem is that > it really has no natural home. It uses asyncio, so makes no sense to > put in subprocess. It doesn't fit the typical asyncio behavior, so > doesn't make sense to put in asyncio. The required functionality isn't > big enough to warrant a submodule anywhere. Heck, it's even way too > small to toss into an external PyPI module. Seems perfect for the Cheesehop to me. Tres. - -- ======= Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlM1iucACgkQ+gerLs4ltQ4RygCfQOjBD7jTZU5ILub/sKxGYqH8 8v8AoKkv2ePkRn3X43CpGBQNeB9uNufQ =xgSe -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] collections.sortedtree
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/27/2014 04:11 AM, Stephen J. Turnbull wrote: > Maybe. That depends on if you care about the convenience of folks > who have to get new modules past Corporate Security, but it's easier > to get an upgrade of the whole shebang. I don't think it's ever > really been resolved whether they're a "typical case that won't go > away" or a special group whose special needs should be considered. ISTM that such concerns should be addressed via some kind of paid support contract (a la RHEL), and not used to drive decisions for the underlying FLOSS project. The existence of aggregated resources from such a support organization would then be relevant to the "include / exclude" discussion: presumably the support organization could fund the maintenance of the otherwise-excluded module based on its customers' paid-for needs. Tres. - -- ======= Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlM1jtQACgkQ+gerLs4ltQ5OOgCdHeOjBjpfJ1w5mkAWZsajflWK U3wAmgIxnc7BFIaoouQ0kdkCgoF+lMr3 =yhYm -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] collections.sortedtree
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/28/2014 11:57 AM, Stephen J. Turnbull wrote: > So, let me get this straight: you think that one user should pay Red > Hat to vet the package for RHEL, and another user should pay to get > it into Ubuntu, and another user to get it into SuSE? And then the > distros should all pay lawyers to write contracts to make sure that > nobody is paying too much for support in the stdlib when they > eventually get it in? (Except the customers, of course, everybody > will be happy if *they* pay more than they need to.) No, I'm arguing that *if* the concerns you articulate represent a significant number of "corporate* customers (i.e., a "market"), their interests would be better represented by *some* organization who is paid to reflect them. RHEL and Ubuntu LTS could potentially be contributors to that pool. I'm mostly arguing the FLOSS project should feel free to ignore high-maintenance-cost commercial concerns until those concerns bring either blook (funded developer time) or treasure (pooled to pay for the same time) to the table to pay for them. Tres. - -- ======= Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlM1oPAACgkQ+gerLs4ltQ52ZgCg06AobjcZa1lGBDtFzRk6IjEK 6DkAnj33xAkqcDUjLGaT9NP4YtZdkAos =62VL -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] collections.sortedtree
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/28/2014 12:18 PM, Tres Seaver wrote: > I'm mostly arguing the FLOSS project should feel free to ignore > high-maintenance-cost commercial concerns until those concerns bring > either blook (funded developer time) or treasure (pooled to pay for > the same time) to the table to pay for them. Dangit, s/blook/blood/ Tres. - -- ======= Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlM1ocMACgkQ+gerLs4ltQ6k8ACgm+ycaOaqZGsefJU5iu9kL4bS 1e4AmQHq/vb4Q6GV/MNuCZQr4HKG/JER =8fLu -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] collections.sortedtree
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/29/2014 03:46 AM, Stephen J. Turnbull wrote: > I really don't think commercial profit as the motive for a request, > or ability to pay, should be an important reason to *ignore* user > wants. We've already got corrosion on the terminals the leaky batteries-included stdlib (ssl, anyone?). I see nothing wrong with rejecting additional batteries proposed purely FBO organizations who have the kind of policies you describe, but don't contribute blood-or-treasure toward their maintenannce (*especially* because they are in the "enterprise" space, and could be expected to pay for that kind of support). This kind of "Python-in-a-tie" discussion is probably moot for any version of Python that python-dev actually cares about, BTW: by the time such organizations get around to using 3.5, it likely won't even be getting security releases from the core developers. Tres. - -- ======= Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlM3Q2wACgkQ+gerLs4ltQ7Y5QCdGhrpenkXJnRXoseVabQDwJHX 0zcAn0tAf6iHT276oxjZS/ZhPu49wF8M =6Gci -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 4?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/03/2014 10:36 AM, R. David Murray wrote: > More seriously, I don't believe there should ever be a Py4k the way > there was a Py3k, and would prefer not to feed any rumours that there > might be. Amen! Tres. - -- ======= Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlM9dDoACgkQ+gerLs4ltQ6ikACgrneAqvKimcm64/AKCbFmp4pn zEoAoK0q6nFXDDRL+UY3zI/PPFDvr3cg =gTu1 -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] arguments policy: **kwargs.pop()
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 04/10/2014 10:12 PM, Christian Tismer wrote:
> I always used the policy that arguments are never changed by a
> function, unless explicitly stated. But since I see this pattern quite
> frequently, I wanted to ask if I am right by thinking this way, or if
> the general policy is more like "arguments may be destroyed by
> default".
>
> What do you think? Is this bad style and should be noticed somewhere,
> or is the caller supposed to protect the arguments, or are my worries
> useless?
The caller can't know or care that the function / method pops arguments::
$ python
Python 2.7.3 (default, Feb 27 2014, 19:58:35)
[GCC 4.6.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> def foo(**kw):
... bar = kw.pop('bar', 'BAR')
... print 'bar: %s' % bar
... print 'kw: %s' % kw
...
>>> foo()
bar: BAR
kw: {}
>>> foo(bar='baz')
bar: baz
kw: {}
>>> foo(bar='baz', bam='qux')
bar: baz
kw: {'bam': 'qux'}
>>> mykw = {'bar': 'baz', 'bam': 'qux'}
>>> foo(**mykw)
bar: baz
kw: {'bam': 'qux'}
>>> mykw
{'bam': 'qux', 'bar': 'baz'}
because the caller gets its own copy of 'kw', even when called with an
existing dict.
Tres.
- --
===
Tres Seaver +1 540-429-0999 tsea...@palladion.com
Palladion Software "Excellence by Design"http://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlNHZhwACgkQ+gerLs4ltQ5RLQCeMaFvMDNexmCw9ggbg34w+AjP
DKMAn1U1WRGW9PV8R/xqJs1HPWUBVEse
=A8nP
-END PGP SIGNATURE-
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Appeal for reviews
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/12/2014 08:30 PM, Stephen J. Turnbull wrote: > it's a matter of time before the contribution is integrated. Our current backlog is bad enough that many contributions are effectively wasted: they rot on the vine before they can be merged. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlNJ4pUACgkQ+gerLs4ltQ4WIACfeoWID19lDf1wpFF2vtl1ZHRk q6gAnRrwLETLirZ6ulS0NivLmYcOOkzF =VHtW -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Mercurial sluggishness (was: this is what happens if you freeze all the modules required for startup)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 04/15/2014 11:34 AM, Skip Montanaro wrote:
> I find it hard to believe that freezing the stdlib is going to lower
> the barrier enough for the Mercurial folks, if, in fact, import
> slowness is their main reason for not moving to 3.x.
My understanding of what Matt said at the language summit is that the
need to support really old versions of Python 2.x (back to 2.4) is a big
part of the holdup ("straddling" is *much* more painful without
constraining to
Python2 >= 2.6).
As I heard it, the real reason for the inertia is that the Python3 port
is a lot of effort / pain for zero perceived gain outside of "because it
is the Right Thing(TM)." After my porting experience, I can sympathize
with that sensibility, and my stuff gets an advantage (frameworks /
libraries marketing to Python3 devs) that Hg doesn't (most users don't
really care which Python is used to drive the standalone tool).
Tres.
- --
=======
Tres Seaver +1 540-429-0999 tsea...@palladion.com
Palladion Software "Excellence by Design"http://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlNNVHAACgkQ+gerLs4ltQ4lpwCeJTYvfBBlE3cS+eq+kA4/zEi3
R+8AnRy4HYLRZ4DHhHDop/8A86MJt5Ei
=fORL
-END PGP SIGNATURE-
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] this is what happens if you freeze all the modules required for startup
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/17/2014 06:06 PM, Brett Cannon wrote: > On Thu Apr 17 2014 at 5:21:14 PM, "Martin v. Löwis" > wrote: > >> Am 17.04.14 20:47, schrieb Brett Cannon: >>> Because people keep bringing it up, below is the results of >>> hacking up the interpreter to include a sys.path entry for >>> ./python35.zip instead of hard-coding to /usr/lib/python35.zip and >>> simply zipped up Lib/ recursively. TL;DR, zipimport performance no >>> longer measures up (probably because of stat caching and such that >>> importlib introduced). >> >> [I found the answer on what is being compared in replies] >> > > Yeah, I did it in under 5 minutes on a whim so I wasn't entirely > thinking when I posted the numbers. > > >> >> So how did you create the zip file? > > > zip ../python35.zip -r . > > >> Any chance that you may have compressed the pyc files? I think you want 'zip -0' to avoid the compression. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlNQUzMACgkQ+gerLs4ltQ53XACcCihQVdb9h4RSnOphhkzu8AjU JsAAoJXClEcf4/McqA610Lh5SDdeHdhW =6pNL -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 469: Restoring the iterkeys/values/items() methods
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/20/2014 07:37 AM, Paul Moore wrote: > Ultimately, every time we add *any* sort of compatibility feature to > Python 3 (Unicode literals, bytes interpolation, this) we are sending > the message that we made a mistake in the design of Python 3. It's > certainly possible that's the case (we didn't have a lot of hard data > to go on) but I do think we should have a little more confidence in > our judgement here. We clearly made mistakes, especially in how we thought migration would occur: nobody expected that we would see straddling / compatible subset as the dominant porting strategy. Re-adding features to make the strategy that works less painful is just acknowledging that fact. Mark such features as BBB-only / deprecated-but-never-to-be-removed, and move on: "practicality beats purity". Tres. - -- ======= Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlNT4gcACgkQ+gerLs4ltQ4a3wCfcKZWldlrPzNn6byYJrCxm1XG ttUAniKTQ6ma0n7XNIMf0lP4A1zexT6j =AkQ+ -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] We cannot fix all issues: let's close XML security issues (not fix them)
On 09/06/2018 11:05 AM, Ryan Gonzalez wrote: > Thought: what if there's a label on the bug tracker meaning roughly "we're > probably not going to fix this anytime soon, but we won't mind someone > stepping up"? "help-wanted" Tres. -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Communication channels
On 10/01/2018 07:19 AM, Victor Stinner wrote: > Some core developers are also active on Twitter. Some ideas were first > discussed on Twitter. You may want to follow some of them. Incomplete > list of core devs that I follow: I'm pretty strongly -1 on the notion that folks who subscribe python-dev, BPO, and the github repositories should need to *also* follow an arbitrarily-growing set of Twitter accounts: how would one know if a new one popped into being? How likely is it that everything a given Python developer tweets is relevant for the Python development community? Tres. -- ======= Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] dear core-devs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/01/2018 06:41 PM, Michael Felt wrote: > And, while you may not give a damn about anything other than Windows, > macos and/or Linux - there are other platforms that would like a > stable Python. Michael, I can understand the frustration you feel: you have been putting effort into a labor of love geting Python support on AIX (back?) into shape, and feel that your efforts are unappreciated, or worse, that they will be waste d. The key thing to realize about the various core developers (and the broader Python and open source communities) is that their attention is a heavily over-committed resource: it isn't that folks here aren't benevolent toward your efforts, but rather that each of them (us?) makes decisions every day juggling which projects / tasks to give the minutes / hours we have available. In the common case, the "triage" involves scrathing an itch: this bug affects me / my work, that feature would make my life / my employment simpler, etc. Even where there are minutes available, the "is reviewing this feasible for me?" question kicks in. Because AIX is relatively narrow in the scope of folks it impacts, the average, overcommitted developer is likely to see a bug report, or even a pull request, which makes stuff build on AIX and say, "Hmm, I don't know enough to evalute that one, I'll leave it to folks who do know (and by implication, who have some skin in the game)." Even for more consumer-focused platforms, it has historically been harder to get attention for bugs / patches which affect only a single platform (Windows file locking semantics, or the Mac installer, etc.) One key way to get past that hurdle is to slice the size of each "thing" down as fine as possible: e.g., a pull request adding a single "#ifdef AIX" block to one file. Anything more than a screenful of diff is likely to trigger the "let someone else review it" pattern, whereas being able to scan the patch at a glance lets even a non-itchy reviewer decide, "well, at least it can't hurt anything, give it a shot." Once you've gotten a number of those small patches merged, you will find that you've built a relationship with the folks who have been reviewing them, and that they are more likely to pass them, and to review larger ones, at least in part because *you* will have learned more about what is needed in terms of code style, documentation, test coverage, etc., and *they* will have learned to trust your judgement. I'm sorry it isn't easier, Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v2 iEYEARECAAYFAluyzyYACgkQFXKVXuSL+CMAHQCfXxFKpKyBXQg3dBSPY8MYOwh1 djsAnitN3SjTt+xwDdnT2NvTs965wEjR =Bl8Z -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fwd: PEP 426 is now the draft spec for distribution metadata 2.0
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/19/2013 09:37 PM, Paul Moore wrote: > On 20 February 2013 00:54, Fred Drake wrote: >> I'd posit that anything successful will no longer need to be added >> to the standard library, to boot. Packaging hasn't done well >> there. > > distlib may be the exception, though. Packaging tools are somewhat > unique because of the chicken and egg issue involved in having a > packaging tool with external dependencies - who installs your > dependencies for you? So enabling technology (library code to perform > packaging-related tasks, particularly in support of standardised > formats) could be better available from the stdlib. The big blocker there is that users can't rely on having it in the stdlib until after they drop Python < 3.4 (assuming accelearated absorption) or even 3.5. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlEkTAsACgkQ+gerLs4ltQ6VBgCePncI4cX7a8NEN6lj98CVBdAE UTUAnA+6zo8Zjmp6T4n0uL804PnHHvZ8 =OT8w -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] XML DoS vulnerabilities and exploits in Python
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/20/2013 06:22 PM, Antoine Pitrou wrote: > On Wed, 20 Feb 2013 18:21:22 -0500 Donald Stufft > wrote: >> On Wednesday, February 20, 2013 at 6:08 PM, Antoine Pitrou wrote: >>>> It's not a distributed DoS issue, it's a severe DoS >>>> vulnerabilities. A single 1 kB XML document can kill virtually >>>> any machine, even servers with more than hundred GB RAM. >>>> >>> >>> Assuming an attacker can inject arbitrary XML. Not every XML >>> document is loaded from the Internet. >> >> Even documents not loaded from the internet can be at risk. Often >> times security breaches are the result of a chain of actions. You >> can say "I'm not loading this XML from the internet, so therefore I >> am safe" but then you have another flaw (for example) where you >> unpack a zip file without verifying there are not absolute paths and >> suddenly your xml file has been replaces with a malicious one. > > Assuming your ZIP file is coming from the untrusted Internet, indeed. > Again, this is the same assumption that you are grabbing some > important data from someone you can't trust. > > Just because you are living in a Web-centric world doesn't mean > everyone does. There are a lot of use cases which are not impacted by > your security rules. Bugfix releases shouldn't break those use cases, > which means the security features should be mostly opt-in for 2.7 and > 3.3. Two words: "hash randomization". If it applies to one, it applies to the other. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlElYScACgkQ+gerLs4ltQ4QgwCfctL8/FmnboJWozyPcSE1xbb2 wwIAoNVc2hoQci9G2M6g/keNNsN5RR0O =Q9IX -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] XML DoS vulnerabilities and exploits in Python
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/20/2013 09:08 PM, Barry Warsaw wrote: > On Feb 21, 2013, at 10:38 AM, Nick Coghlan wrote: > >> - make it possible to enable safer behaviour globally in at least >> 2.7 and 3.3 (and perhaps in 2.6 and 3.2 security releases as well) > > I want to be fairly conservative with 2.6.9. I believe that the same rationale should apply as that for adding hash randomization in 2.6.8: this is at least as bad a vulnerability, with many more vectors of attack. Tres - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlElo/cACgkQ+gerLs4ltQ4urQCg2Kyr6CKZPp35fAK1G4OtzYc+ XD8An0fJZw5DHRxg1JPe9AzcLqpvRZc5 =hmpM -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] XML DoS vulnerabilities and exploits in Python
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/21/2013 01:53 AM, Antoine Pitrou wrote: > On Thu, 21 Feb 2013 11:37:47 +1100 Steven D'Aprano > wrote: >> >> It's easy to forget that malware existed long before the Internet. >> The internet is just a transmission vector, it is not the source of >> malicious files. The source of malicious files is *other people*, >> and unless you never use XML files you didn't generate yourself, you >> cannot completely trust the source. You might trust your colleagues >> to not *intentionally* pass you a malicious XML file, but they may >> still do so accidentally. > > That's in theory very nice, but in practice security in everyday > computing hasn't really been a concern before the massification of > Internet access. > > (yes, there have been viruses on mainstream platforms such as the > Amiga, but it was pretty minor compared to nowadays, and nobody cared > about potential DoS attacks for example) > > So, as for XML files, we are talking about a DoS vulnerability. It > will take more than a single file to make a DoS attack really > annoying, which means the attacker must pollute the source of those > XML files in a systemic way. It's not "a single XML file will smuggle > confidential data out of the building". Antoine, A single, small,, malicious XML file can kill a machine (not just the process parsing it) by sucking all available RAM. We are talking hard lockup, reboot-to-fix-it sorts of DOC here. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlElzMQACgkQ+gerLs4ltQ7fDQCgmvvurNi5VtWA+4mqcz4tpUhR rNUAnRtpcKMFCM3z8qRKNfinAE9ly9fX =y+eM -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Semantics of __int__(), __index__()
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/03/2013 11:49 AM, Steven D'Aprano wrote: > -1 on forcing __int__, __str__, __float__ etc. to return instances of > the built-in types. - -1 as well, for the reasons Steven lists. The only quasi-legitimate reason I know of for checking 'type(x) is int' rather than 'isinstance(x, int)' is speed. Tres. - -- ======= Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlFcV/wACgkQ+gerLs4ltQ6OBwCg0YMyUdiji82TwYQZTx85F9cJ wmMAoKBL13C+a4MN640jL5X+X+G9RP5b =8q3C -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Semantics of __int__(), __index__()
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/03/2013 01:50 PM, Ethan Furman wrote: > On 04/03/2013 10:46 AM, Barry Warsaw wrote: >> On Apr 04, 2013, at 03:04 AM, Steven D'Aprano wrote: >> >>> On 04/04/13 01:16, Barry Warsaw wrote: >> >>>> the other built-in types-as-functions, so int() calls __int__() >>>> which must return a concrete integer. >> >>> Why must it? I think that's the claim which must be justified, not >>> just taken as a given. When we call n = int(something), what's >>> the use-case for caring that n is an instance of built-in int but >>> not of a subclass, and is that use-case so compelling that it must >>> be enforced for all uses of int() etc.? >> >> It's a consistency-of-implementation issue. Where built-in types >> are callable, they return concrete instances of themselves. This is >> true for e.g. list, tuple, dict, bytes, str, and should also be true >> of int. Given that requirement, we still don't have to mandate that __int__ return an actual instance of the int type: the coercion could happen inside int() (as it would for any non-subclass). Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlFcgVcACgkQ+gerLs4ltQ4ScwCfScssK/Cv74lPitQxbygmk5h/ RGoAnj2yUEgmEgorJi8GZh0GEB/iJrN1 =0I+y -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] The end of 2.7
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/08/2013 04:40 PM, Skip Montanaro wrote: > I'm really amazed at how many people seem to have the impression that > porting to Python 3 should be no big deal. FWIW, the effort of porting the "modern" bits of the Zope ecosystem (the ones I still use in Pyramid apps today, meaning the component architecture, the ZODB, and a few others) soaked up basically all of my FLOSS time between the two Santa Clara PyCons. To be fair, some of that effort went into improving test coverage, docs, etc., to ensure that the apps running against the ported librarties wouldn't break, even on Python2: but is was *not* a trivial effort. Tres. - -- ======= Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlFjMdYACgkQ+gerLs4ltQ62mACfSxdVNlTpSusR5MGMmuIw7lhf 3yIAoIJd6P8KoewUAjJnViuziWQWPHb8 =Bpul -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Why can't I encode/decode base64 without importing a module?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/23/2013 09:29 AM, Stephen J. Turnbull wrote: > By RFC specification, BASE64 is a *textual* representation of > arbitrary binary data. It isn't "text" in the sense Py3k means: it is a representation for transmission on-the-wire for protocols which requre 7-bit-safe data. Nobody working with base64-encoded data is going to expect to do "normal" string processing on that data: the closest thing to that is splitting it into 72-byte chunks for transmission via e-mail. Tres. - -- ======= Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlF4D9YACgkQ+gerLs4ltQ5nUACfWm4YEMarjUb7fEEpP+aMtaQr a7kAn1Pc8ufUwJzKHD0DgSxQ4H/uqf82 =CzTZ -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Why can't I encode/decode base64 without importing a module?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/25/2013 01:43 AM, Antoine Pitrou wrote: > On Thu, 25 Apr 2013 04:19:36 +0200 Lennart Regebro > wrote: >> On Thu, Apr 25, 2013 at 3:54 AM, Stephen J. Turnbull >> wrote: >>> RFC 4648 repeatedly refers to *characters*, without specifying an >>> encoding for them. > [...] >> >> Base64 is an encoding that transforms between 8-bit streams. > > No, it isn't. What Stephen wrote above. Stephen was incorrect: the base64 standard is about encoding a binary stream (8-bit bites) onto another binary stream (6-bit bytes), but one which can be safely transmitted over a 7-bit-only medium. Text in Py3ks sense is irrelevant. >> Either you get a "LookupError: unknown encoding: base64", which is >> what you get now, or you get an UnicodeEncodingError if the text is >> not ASCII. We don't want the latter, because it means that code that >> looks fine for the developer breaks in real life because the >> developer was American > > That's bogus. By the same argument, we should suppress any encoding > which isn't able to represent all possible unicode strings. That's > almost all encodings provided by Python (including utf-8, if you > consider lone surrogates). > > I'm sorry for Americans, but they *still* must know about character > encodings, and be ready to handle UnicodeErrors, when using Python 3 > for encoding/decoding bytestrings. There's no way around it. WHat does that snark have to do with this discussion? base64 has no more to do with character set encodings than it does the moon. It would be a "transform" (bytes -> bytes), not an "encoding". Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlF5Nc4ACgkQ+gerLs4ltQ7f9ACgx19dzyLXCDzkLkWITSU+7WyD XEMAn38mZgK8F1/FGWJc+ANOJz2tfHI/ =qpSL -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 435 -- Adding an Enum type to the Python standard library
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/25/2013 12:39 PM, Ethan Furman wrote: > Animals is a class. Giving Animals a parameter (such as 1 or 'ant') > should return the instance that matches. Animals is *not* a class -- it just uses the class syntax as a convenient way to set up the names used to construct the new type. (This subtlety is why the metaclass hook is reputed to make peoples' brains explode). > This is how classes work. Not really. Normal classes, when called, give you a new instance: they don't look up existing instances. Tres. - -- ======= Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlF5fa4ACgkQ+gerLs4ltQ7FSwCgzhcoXonMO/7W+xYMpM4EvtTj nPIAnAkHtWxFMaU3dqfFUclNQkUcJ2FZ =C0/7 -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP-435 reference implementation
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/01/2013 12:14 PM, Guido van Rossum wrote: > But we'd probably have to give up something else, e.g. adding methods > to enums, or any hope that the instance/class/subclass relationships > make any sense. I'd be glad to drop both of those in favor of subclassing: I think the emphasis on "class-ness" makes no sense, given the driving usecases for adopting enums into the stdlib in the first place. IOW, I would vote that real-world usecases trump hypothetical purity. Tres. - -- ======= Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlGBQEMACgkQ+gerLs4ltQ6myQCZAZqKCR/6H6I8bogHtSwhTM9I ok8AnjBKfFyuse6caMF085wBHvlrf0uA =nJ5C -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Mysterious Python pyc file corruption problems
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/15/2013 04:58 PM, Barry Warsaw wrote: > This leads me to hypothesize that the bug is due to an as yet > unidentified race condition during installation of Python source code > on Ubuntu, which is normally when we automatically byte compile the > source to .pyc files. Any chance you are using 'detox' or the equivalent to run tests on mutliple interpreters in parallel? The only "bad marshall data" errors I have seen lately seemed to be provoked by that kind of practice. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlGUBvkACgkQ+gerLs4ltQ7nCwCcCfcAEGEN26qjQ9sGPaFRx1o4 DhwAoIlNwVU2lcJQ/hs5vQ1PXYT1uUwl =0s+X -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Mysterious Python pyc file corruption problems
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/16/2013 06:59 PM, Nick Coghlan wrote: > 3.2 uses __pycache__, so it should only potentially conflict within > the same version. > > I haven't heard any rumblings about anything like this in Fedora or > RHEL, so my suspicions still lean towards a Debian or Ubuntu specific > background service somehow managing to interfere. However, I'll ask > explicitly on the Fedora Python list to see if anyone has encountered > anything similar. I can confirm at least that I have seen this problem within the last two weeks on Ubuntu boxes unrelated to the thw Debian / Ubuntu build infrastruction. Tres. - -- ======= Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlGVqIgACgkQ+gerLs4ltQ6ksACePs7jO1TynGm3kNodpV4lPA2b VbgAoNNHMmQhJQhOvxuHMO/LFyv+Umho =KNdc -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Mysterious Python pyc file corruption problems
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/17/2013 12:26 PM, Barry Warsaw wrote: > On May 16, 2013, at 11:48 PM, Tres Seaver wrote: > >> I can confirm at least that I have seen this problem within the last >> two weeks on Ubuntu boxes unrelated to the thw Debian / Ubuntu >> build infrastruction. > > Hi Tres. If you see this happen, *please* get in touch with me, > preferably before you fix it ;). I'd like to do some additional > analysis on a broken system in semi-realtime. Wilco (although I don't know for sure what provoked it: my memory is that it was while running 'tox' or 'detox' for ZODB). Tres. - -- ======= Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlGWfCAACgkQ+gerLs4ltQ5YcQCguzlxAP8InrLEgdGx7JiK0as4 z9MAnR53bubpntt+272Y0BNYlEO8YcdI =LSAR -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Purpose of Doctests [Was: Best practices for Enum]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/19/2013 10:48 AM, Guido van Rossum wrote: > Anyway, if you're doing arithmetic on enums you're doing it wrong. Hmm, bitwise operations, even? Tres. - -- ======= Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlGZMoAACgkQ+gerLs4ltQ79qwCgq6FWTl6ZDIDctBg69In47YB2 +FkAnj5cEyw1szQ8GCl6aQ9+aGKcwp3y =d/xt -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Purpose of Doctests [Was: Best practices for Enum]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/19/2013 12:14 PM, Dan Stromberg wrote: > On Sat, May 18, 2013 at 11:41 PM, Raymond Hettinger < > raymond.hettin...@gmail.com> wrote: > >> >> On May 14, 2013, at 9:39 AM, Gregory P. Smith >> wrote: >> >> Bad: doctests. >> >> >> I'm hoping that core developers don't get caught-up in the "doctests >> are bad meme". >> > > Don't doctests intended for CPython not work on Jython, Pypy, > IronPython... > > I've been avoiding them for this reason. "Naive" doctests depend a lot on repr, and hence tend to break even between minor releases of CPython. Folks who use a lot of them apply a great deal of elbow grease to working around that problem, e.g. through "renoormalizing" the output: https://github.com/zopefoundation/zope.testing/blob/master/src/zope/testing/renormalizing.txt Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlGZM1YACgkQ+gerLs4ltQ6zRACgx266WAzy1RDX0vOm7fThXzi5 zX4AoNyZFGBOML2XR4ZOecXwzG6XaHW+ =yGon -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Purpose of Doctests [Was: Best practices for Enum]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/19/2013 07:22 PM, Mark Janssen wrote: > On Sun, May 19, 2013 at 1:13 PM, Tres Seaver > wrote: >> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 >> >> On 05/19/2013 10:48 AM, Guido van Rossum wrote: >>> Anyway, if you're doing arithmetic on enums you're doing it >>> wrong. >> >> Hmm, bitwise operations, even? > > I think it's rather pointless to do bitwise operations on python > enums. We're not that close to the machine. What, nobody uses Python to do networking? How abaout driving the GPIO on a RaspberryPI? Using the bitwise operators to compbine named "flag" values seems like a pretty natural fit to me (if you don't care about the specific values, you don't need IntEnum anyway). Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlGaEDwACgkQ+gerLs4ltQ5eXACfTrmegJsYDvbuwrbr5zyjwWV+ jMUAoIHQBi/qkm+MClGeh/ZwWOUGCMFm =4ey/ -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Bilingual scripts
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05/28/2013 11:41 AM, R. David Murray wrote:
> I have the same complaint about setuptools entry-point scripts, where
> I still haven't figured out how to go from what is in the file to the
> code that actually gets called.
Hmm, just dump the 'entry_points.txt' file in the named distribution's
EGG-INFO directory? E.g.:
$ cat bin/pip
#!/path/to/virtualenv/bin/pythonX.Y
# EASY-INSTALL-ENTRY-SCRIPT: 'pip==1.3.1','console_scripts','pip'
__requires__ = 'pip==1.3.1'
import sys
from pkg_resources import load_entry_point
if __name__ == '__main__':
sys.exit(
load_entry_point('pip==1.3.1', 'console_scripts', 'pip')()
)
$ cat
lib/pythonX.Y/site-packages/pip-1.3.1-pyX.Y.egg/EGG-INFO/entry_points.txt
[console_scripts]
pip = pip:main
pip-X.Y = pip:main
Tres.
- --
===
Tres Seaver +1 540-429-0999 tsea...@palladion.com
Palladion Software "Excellence by Design"http://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/
iEYEARECAAYFAlGk2K0ACgkQ+gerLs4ltQ6WaACZAbdz7k3sdM21DNx0mzcecY93
hvYAoJTwA2l3OvSoYStzGmsJ+N16JDwM
=YHcy
-END PGP SIGNATURE-
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Bilingual scripts
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05/28/2013 05:52 PM, R. David Murray wrote:
> On Tue, 28 May 2013 12:17:49 -0400, Tres Seaver
> wrote:
>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1
>>
>> On 05/28/2013 11:41 AM, R. David Murray wrote:
>>> I have the same complaint about setuptools entry-point scripts,
>>> where I still haven't figured out how to go from what is in the
>>> file to the code that actually gets called.
>>
>> Hmm, just dump the 'entry_points.txt' file in the named
>> distribution's EGG-INFO directory? E.g.:
>>
>> $ cat bin/pip #!/path/to/virtualenv/bin/pythonX.Y #
>> EASY-INSTALL-ENTRY-SCRIPT: 'pip==1.3.1','console_scripts','pip'
>> __requires__ = 'pip==1.3.1' import sys from pkg_resources import
>> load_entry_point
>>
>> if __name__ == '__main__': sys.exit( load_entry_point('pip==1.3.1',
>> 'console_scripts', 'pip')() )
>>
>> $ cat
>> lib/pythonX.Y/site-packages/pip-1.3.1-pyX.Y.egg/EGG-INFO/entry_points.txt
>>
>>
[console_scripts]
>> pip = pip:main pip-X.Y = pip:main
>
> I'm afraid I'm still not enlightened.
>
> I'm sure I would understand this if I had ever set up an entry point,
> since I would have had to read the docs on how to do it. But I never
> have.
>
> So, my point is that the information on what python code is actually
> being called ought to be in the stub script file, as a comment if
> nothing else, for discoverability reasons.
>
> I'm not bothered enough to work up a patch, though :)
It is there already:
# EASY-INSTALL-ENTRY-SCRIPT: 'pip==1.3.1','console_scripts','pip'
Which says, load the entry point named 'pip' from the 'console_scripts'
entry point group in the 'pip 1.3.1' distribution.
The 'entry_points.txt' metadata file specifies that that entry point is a
function named 'main' inside the 'pip' package itself.
Ters.
- --
===
Tres Seaver +1 540-429-0999 tsea...@palladion.com
Palladion Software "Excellence by Design"http://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/
iEUEARECAAYFAlGlZesACgkQ+gerLs4ltQ50xACeJUBMjAvMBaOm63Viigz2bvkP
S5gAl2w4WAxgasXie10DMtHJOyRRFvA=
=34KH
-END PGP SIGNATURE-
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Clean way in python to test for None, empty, scalar, and list/ndarray? A prayer to the gods of Python
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/14/2013 04:55 PM, R. David Murray wrote: > This I sort of agree with. I've often enough wanted to know if > something is a non-string iterable. But you'd have to decide if > bytes/bytearray is a sequence of integers or a scaler... In fifteen years of Python programming, I have literally *never* wanted to iterate over 'str' (or now 'bytes'). I've always considered the fact that Python made them iterable by default (rather than e.g. defining a method / property to get to an iterable "view" on the underlying string) a wart and a serious bug magnet. Tres. - -- ======= Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlG8Y7MACgkQ+gerLs4ltQ6EbwCfYlC3JKL22HK7WgxJLAh9Gk2H R4cAn2+ijAkebHuF92txeddBq99L/zqn =bLkO -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Clean way in python to test for None, empty, scalar, and list/ndarray? A prayer to the gods of Python
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 06/15/2013 09:15 AM, Donald Stufft wrote:
> I never want to iterate, but I love slice syntax and indexing. Don't
> think you can have that w/o being able to loop over it can you? Maybe
> I'm just thinking slow since I just woke up.
You could if '__iter__' raised an error ('NotIterable', maybe) which
defeated the '__getitem__'/'__len__'-based fallback.
Tres.
- --
=======
Tres Seaver +1 540-429-0999 tsea...@palladion.com
Palladion Software "Excellence by Design"http://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/
iEYEARECAAYFAlG8cFoACgkQ+gerLs4ltQ7KcgCfdFCEkp2gBeuUgn/KooY7F5HX
Jm8An2bwq8QoplwJ1MqIbS76m+xdl/Mk
=6hA9
-END PGP SIGNATURE-
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Clean way in python to test for None, empty, scalar, and list/ndarray? A prayer to the gods of Python
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/15/2013 04:11 PM, Terry Reedy wrote: > On 6/15/2013 8:53 AM, Tres Seaver wrote: > >> In fifteen years of Python programming, I have literally *never* >> wanted to iterate over 'str' (or now 'bytes'). > > If so, it is because you have always been able to use pre-written > methods and functions that internally do the iteration for you. Given that strings are implemented in C, there is no real "iteration" happing (in the Python sense) in their methods. What stdlib code can you point to that does iterate over them in Python? I.e.: for c in stringval: ... Even if there were, aren't you proving my point? The fact that strings are implicitly iterable injects all kinds of fur into methods which take either a single value or an iterable as an argument, e.g.: def api_function(value_or_values): if isinstance(value_or_values, STRING_TYPES): value_or_values = [value_or_values] elif isinstance(value_or_values, collections.abc.Iterable): value_or_values = list(value_or_values) else: value_or_values = [value_or_values] The bugs that leaving the first test out yields pop up all over the place. >> I've always considered the fact >>> that Python made them iterable by default (rather than e.g. >>> defining a method / property to get to an iterable "view" on the >>> underlying string) > > .__iter__ is that method. But it is *on be default*: I was describing something which has to be requested in ways that don't get triggered by syntax, and doesn't make strings look "non-scalar" for APIs like the one above. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlG84H0ACgkQ+gerLs4ltQ56RQCgks8R52f41RwJ+v9oteOBC3qY kIIAoIHmg+zcmJpV3v/gAhkKJfbNKufj =ZeRB -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] backported Enum
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/15/2013 05:14 PM, Barry Warsaw wrote: > On Jun 15, 2013, at 12:46 PM, Ethan Furman wrote: > >> So I have the stdlb 3.4 Enum backported for both earlier 3.x and >> back to 2.4 in the 2.x series. >> >> I would like to put this on PyPI, but the `enum` name is already >> taken. >> >> Would it be inappropriate to call it `stdlib.enum`? > > The last upload was on 2009-08-25. Maybe Ben Finney's abandoned it > and wouldn't mind giving up the enum PyPI name? That would screw anybody already using the existing distributions pretty badly. Tres. - -- ======= Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlG84O0ACgkQ+gerLs4ltQ71qwCgo4uubYXVw/qvARESfzPLzFYZ Fb8AnjB5ZcwupMoQ6SP6r7Xl26Hg3wpQ =u3L7 -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 446: Add new parameters to configure the inherance of files and for non-blocking sockets
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/04/2013 07:03 AM, Victor Stinner wrote: > Title: Add new parameters to configure the inherance of files and for > non-blocking sockets Not commenting on either the form or the substance (pun intended), but the word you want is "inheritance" -- "inherence" is a valid term[1], but would a good deal stranger notion to apply to a file descriptor. ;) [1] https://en.wikipedia.org/wiki/Inherence Platonic'ly, Tres. - -- ======= Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlHV0VoACgkQ+gerLs4ltQ4YCQCgp6mFPxEVVoXAXib/jrChjRxu QkAAoLJQIfBCQezj61LCAgmVaE1kwNmM =yiPj -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Tweaking PEP 8 guidelines for use of leading underscores
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/16/2013 07:09 AM, Nick Coghlan wrote: > I did find it interesting that we *don't* explicitly advise against > the use of "import *" for anything other than optional accelerator > modules or republishing internal interfaces through a public API, > even though we advice against the practice in the tutorial. Perhaps > another oversight worth correcting? +1. 'from foo import *' (from any source other than another module in the same package) is a code stench far worse than anything else PEP8 proscribes. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlHl2GsACgkQ+gerLs4ltQ6+1QCgmu5k6p5otzPxvzGh5mA1Ch7t 2f0AoK2a0/m144bnIwBFLLuY9l2bdWMN =878p -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PyPy3 2.1 beta 1 released
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/30/2013 04:39 PM, Philip Jenvey wrote: > PyPy3 2.1 beta 1 > > We're pleased to announce the first beta of the upcoming 2.1 release > of PyPy3. This is the first release of PyPy which targets Python 3 > (3.2.3) compatibility. > > We would like to thank all of the people who donated_ to the `py3k > proposal`_ for supporting the work that went into this and future > releases. > > You can download the PyPy3 2.1 beta 1 release here: > > http://pypy.org/download.html#pypy3-2-1-beta-1 > > Highlights == > > * The first release of PyPy3: support for Python 3, targetting CPython > 3.2.3! > > - There are some `known issues`_ including performance regressions > (issues `#1540`_ & `#1541`_) slated to be resolved before the final > release. > > What is PyPy? == > > PyPy is a very compliant Python interpreter, almost a drop-in > replacement for CPython 2.7.3 or 3.2.3. It's fast due to its > integrated tracing JIT compiler. > > This release supports x86 machines running Linux 32/64, Mac OS X 64 or > Windows 32. Also this release supports ARM machines running Linux > 32bit - anything with ``ARMv6`` (like the Raspberry Pi) or ``ARMv7`` > (like Beagleboard, Chromebook, Cubieboard, etc.) that supports > ``VFPv3`` should work. Wow -- congratulations! Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlH4LbQACgkQ+gerLs4ltQ655ACfXIlTNAldCJdCSjY0Os8xIhLu vl4AoIi8eXqB6Ef/RO2W46iIbQvlX41j =R2vL -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] please back out changeset f903cf864191 before alpha-2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/26/2013 04:36 AM, Antoine Pitrou wrote: > event-driven processing using network librarie Maybe I missed something: why should considerations from that topic influence the design of an API for XML processing? 'feed' and 'close' make much more sense for a parser API, as well has having the benefit of long usage. Tres. - -- ======= Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlIbSRoACgkQ+gerLs4ltQ5lhwCgnG7TLgSkVf+gXSOxO1KP2kLC eLwAn1QbqbHUqJ7bKV6us/nDQ79AYUgk =aN8S -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Coverity Scan Spotlight Python
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/29/2013 07:24 PM, Sturla Molden wrote: > > Do the numbers add up? > > .005 defects in 1,000 lines of code is one defect in every 200,000 > lines of code. > > However they also claim that "to date, the Coverity Scan service has > analyzed nearly 400,000 lines of Python code and identified 996 new > defects – 860 of which have been fixed by the Python community." FWIW: David Wheeler's 'sloccount' reports 800,489 lines of code in the Python 3.3.1 tarball, of which 403,266 lines are Python code, and 368,474 are ANSI C. That defect rate would imply 4 open defects in Python itself. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlIf6e0ACgkQ+gerLs4ltQ6X6wCgosAIUJyGjcBqbeAMLwMH24TJ j3cAoNKPEuKEbVmke2IZuSdtl2nMAFL4 =MoZm -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Offtopic: OpenID Providers
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/05/2013 03:52 PM, Skip Montanaro wrote: >> I think Persona is just too new to see it around much yet. Or maybe >> Mozilla needs better PR. > > The Persona site touts: "Signing in using Persona requires only a > valid email address; allowing you to provide personal information on > as-needed basis, when and where you think it’s appropriate." > > They clearly need a better example site. They chose something called > Voost. Sure enough, all I needed to enter was my Gmail address. That > got me signed in, but then Voost asked me for a bunch of other > personal information (name, gender, birthdate, etc), and wouldn't let > me go any farther without that. :-/ As sith OpenID, the key element to Persona is SSO: you can authenticate without needing to create / remember passwords for every site you visit. Whether a given site chooses to authroize an authenticated-but-otherwise-unknown user to do anything meaningful is logically distinct. +1 for supporting Persona as an alternative to OpenID on all *.python.org servers. Tres. - -- ======= Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlIo6ecACgkQ+gerLs4ltQ6gOwCgrIokRYnddNaNVIVPoY/M4d0k kKcAni6hxXQE4T4QMij3bQHAJwBFX1uW =9ZJP -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Offtopic: OpenID Providers
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/05/2013 04:29 PM, Oleg Broytman wrote: > On Thu, Sep 05, 2013 at 02:50:44PM -0400, Donald Stufft > wrote: >> On Sep 5, 2013, at 2:43 PM, Oleg Broytman wrote: >>> On Thu, Sep 05, 2013 at 02:35:16PM -0400, Donald Stufft >>> wrote: >>>> Persona is the logical successor to OpenID. >>> >>> OpenID lived a short life and died a quiet death. I'm afraid >>> Persona wouldn't live even that much. Dead-born idea, in my so >>> humble opinion. >> >> I don't think there's much evidence to support this. I'm seeing more >> sites support Persona not less. It solves some of the major problems >> with OpenID. > > I have seen exactly 0 (zero) sites that support Persona. Can you point > me? - From the "Mozilla Identity" blog: - - https://webmaker.org/ - - http://bornthiswayfoundation.org/ - - http://firebase.com/ - - https://orionhub.org/ - - http://ting.com/ - - http://www.gnu.org/software/mailman/ - - http://discourse.org/ - - https://dailycred.com/ Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlIo8GoACgkQ+gerLs4ltQ5OtACdEv/XvYKwGuFQESuLn+uBkNzm UUAAn2YY22+YL+tS0WhE+95tIb0USmV7 =cB96 -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Offtopic: OpenID Providers
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/05/2013 04:33 PM, Glenn Linderman wrote: > On 9/5/2013 1:30 PM, Tres Seaver wrote: >> +1 for supporting Persona as an alternative to OpenID on all >> *.python.org servers. > > Is there a Python implementation of Persona I can install on my web > server? - - https://readthedocs.org/projects/django-browserid/ - - https://pyramid_persona.readthedocs.org/en/latest/ Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlIo8SMACgkQ+gerLs4ltQ57xgCfT2xVkJfMtuDjmed6jlhfsD8I fxMAoNHT69tbi3iKtpkyEcSY0lwJosqc =TTJ8 -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Checking in Argument Clinic early?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/15/2013 08:55 AM, Larry Hastings wrote: > So, quick poll: do you approve of me checking Argument Clinic in to > Python 3.4 trunk in its current state before 3.4a4? +1 Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlJdPgsACgkQ+gerLs4ltQ6CIACbB47gAz5px1MGVhRvqY+S0GP/ SYUAnRSQ2e1xqjySgwrFYz7gCuHbWksJ =+QW/ -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Checking in Argument Clinic early?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/15/2013 12:47 PM, Serhiy Storchaka wrote: > 15.10.13 15:55, Larry Hastings написав(ла): >> So, quick poll: do you approve of me checking Argument Clinic in to >> Python 3.4 trunk in its current state before 3.4a4? > > Could you get us a week for preliminary review before checking? I > remember I proposed a little different syntax and I don't know whether > it was taken into account and how a syntax evolved. The syntax compromise was actually hammered out during / after the Language Summit at PyCon US this year: Guido blessed the resulting spec. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlJdd4sACgkQ+gerLs4ltQ4URgCfRqHMQ4ttE+k1p2w7gMGaCsQI JhoAn2rPnbApwcAbd2TZITzG2UinrK+R =KsLA -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Bug in the DELETE statement in sqlite3 module
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/15/2016 12:33 PM, Guido van Rossum wrote: > A point of order: it's not necessary to post three separate "this is > the wrong list" replies. In fact the optimal number is probably close > to zero -- I understand we all want to be helpful, and we don't want > to send duplicate replies, but someone who posts an inappropriate > question is likely to try another venue when they receive no replies, > and three replies to the list implies that some folks are a little too > eager to appear helpful (while reading the list with considerable > delay). When the OP pings the thread maybe one person, preferably > someone who reads the list directly via email from the list server, > could post a standard "wrong list" response. In addition, please don't undermine the "this is the wrong list" message by responding substantively to the OP's query. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBAgAGBQJXYYc/AAoJEPKpaDSJE9HYlSgP/1v+FpEvildmH4fEpZXG+j18 jCt3Q48ffSW22oPhx4lyfZv1Sh3EOsEuHHd3oU7jG9kUtTPyluQQYJiygfCBpSev CP8LonjJxxkFsVwK5SRGcp7JdjiFbLyqUXbtkFM6s2OE7mpXwtbn4suCRJx7MYaO CUkN2h0vAandftV4xu+lp/r7n0l8HLTTOsrUFuPZRbT4dVzKwRcM+ER1W4tCnkgZ bFRXM8YjrUcX/Um2blSi4yZT75TvHjyi44ujbQPsR3OHCPN8GAfAzIVSkbiECP2K xAqT2/h0E6VkGdEymELCMRHvhCI2wFrAoA6nWYCdyR2Ekg7VB/tnr6AGi+SNvP06 BETMf0BRxpd4sXOvS4+ydhBQQpydW4hiw61RHs8xFiy0W7pqp5Zh4ZHHcZBR2KRT TXfoxrwQIBIWKlyBdgv9d0maOWg3uq3I3MqO2vnGj/XRPsjs/BWCX9BYZqpnEATB MasQItCMPoOfmVxlS+cS7rIXXVFdwulm2s5GRZR9PwEuMS8Vmi9A5UyEpshlDYZM ZMPT3CScFOyczVgC3N+LyO7rYaJMlcNQD/HxxQDvpXoYinxQAFo4eVE2+490XN8j Od8n3UIo72+rFyyFJ8A7iBORYF9UD44VrFHQRHROTEvv7dV1OTYSVZcdqBb4Ik6S 8Wl+qMIEm8VcuFKI4b/T =4IaO -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposal: explicitly disallow function/class mismatches in accelerator modules
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/09/2016 09:50 AM, Nick Coghlan wrote: > Given that the issues that arose in this case weren't at all obvious > up front, what do folks think of the idea of updating PEP 399 to > explicitly prohibit class/function mismatches between accelerator > modules and their pure Python counterparts? > > The rationale for making such a change is that when it comes to true > drop-in API compatibility, we have reasonable evidence that "they're > both callables" isn't sufficient once the complexities of real world > applications enter the picture. +1. Might need some clarification: - - "C functions can fall back to ". - - "C classes must fall back to Python classes". Outlining the constraints in the PEP (identical pickling semantics, sublcassability, etc.) might be important, too. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBAgAGBQJXgRCpAAoJEPKpaDSJE9HYNhwP+gN1xGSZlEvrxz5SGrqTneUx 5WDh2oUJzlTFHDrbSMTeGcpoYviWPLWFy0Hw7PBgRhrlA/TS7WA5/4ABde+2Zs0w PN5AaaXZrkGAHvcQZkBzcEY9ITSpeb+GSmLG4Eih30UAuPFnM3M1UYSjEGjVZV23 tYeDTcmORNaBcQDPG8HiidfOArBKTcz8Jd1IimFrYEOFGSsk6DxPWffJ3EkR6qFj FwsktPDZT113AiztrkLt1s8vyLj8JdzkGKJO+fSfOsp70NZCRy1SKi6tJjHfd4e5 qf9qgi9yh39y+VktBV0o83+gkaGlOKIPRCqOYdkOQHl59RT0YWBoRuXrVtmE00fl QoePBxJjVszlzknULLOXptv0B0sv0ZhsXPgID3hhZ0Z78LQ1RG/9fquGGbfOFfe0 qiPR4LZKCTatP4jvxV3PVKJ9NdXb8OKmfF7oEO7t8WZBJUMtpeuKOw5Qj6Am1pTA UUtDuCXeP0rPVE6Nj5p3NuhkVWuW9eX+7v4XhUC+t4c74PeDo+Fx+LjZF/D3WGVr yD2fcoL16mZ/+LWbxblVkhmsNQpyogtZfj/yvnLctMlGfvseMV9tPOe4GG5QLexW HRl3fSMRIi6MjYnxQyeF/vp+eWd6ApK9EIFqYcLWO+AjzXeZ8uS8+ezGzA7ZUvyG GKJB/ThZHTxuszh7kUgq =mRpk -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP487: Simpler customization of class creation
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/14/2016 11:47 AM, Guido van Rossum wrote: > If you intend a PR as a base for discussion you can add a comment > saying e.g. "Don't merge yet". If you call out @gvanrossum, GitHub > will make sure I get a message about it. FWIW, I often use a Github label, "don't merge" (colored red for urgency), to indicate that PRs are still in discussion stage: removing it is a lightweight way to signify that blocking issues have been resolved (in the opinion of the owner/matintainer, anyway). Tres. - -- ======= Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBAgAGBQJXh9P8AAoJEPKpaDSJE9HYsC0QAMPf/J+n35fg7sMjy07/fE8v xXXc+JbqnphnZolX1Xjla8sUD6tSpq0dp234VYeGwm4z19p3U5SYpYX4zzNuYCwE V2AVfdNpY0xwTkoFCbxXTwikZVIGt6o8IQLvqcjlQpCj3wl5A0ggcoaYDnXeKrZd wE4MF4t9YFgdABZ2i2RVbZNoSRUcMa1kKq9BKpnLnq65dPv2yAYQDDbWIatXLLbi 7kxAfK4CjSWR8BKNzo71uJDeVJVyk6N2nWLuGNOEff8BVZe83cG/2SRjRGALSb0h kV6FdPhwIhoZ+KrVvkLcbJYpUykBAPK68VSnomXNU14jpY9a3zqEIrirB4YLM3tS 9Ov2GYH+AhDPQ840B197mmkGN4nu/d52jCHPfecgccz2gooy+qoK3FRrMlshTTaD dbnTlNm/mkEBad8dz7l/u7cGvVG+k5AiFCGkOMikg4So0xXw7C9ulCQhoARWa0DS J0gTqEGHzGqYAwMXvWxobvlm3HxcxutWuYYx7vD0DRKrPRdpz/ELE7XpOh5bPjjU sEpt7gaAn/q962QorCDRopvqgd7MeRkrAdPKJzhCIeSUp9+Y/oqolZ/my4uEXSju W8WHWx41ioDvoUEHFW3pYljSN075STP21SCuxJh+GBDOVS2HsMXEb09wxM81GOAt V/mBLuZeptsVMiVSQk6J =/KS/ -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP487: Simpler customization of class creation
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/14/2016 02:10 PM, Brett Cannon wrote: > On Thu, 14 Jul 2016 at 11:05 Tres Seaver > wrote: > >> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 >> >> On 07/14/2016 11:47 AM, Guido van Rossum wrote: >> >>> If you intend a PR as a base for discussion you can add a comment >>> saying e.g. "Don't merge yet". If you call out @gvanrossum, >>> GitHub will make sure I get a message about it. >> >> FWIW, I often use a Github label, "don't merge" (colored red for >> urgency), to indicate that PRs are still in discussion stage: >> removing it is a lightweight way to signify that blocking issues >> have been resolved (in the opinion of the owner/matintainer, >> anyway). >> > > Just start the title with `[WIP]` and it will be obvious that it's a > work-in-progress (it's a GitHub idiom). De gustibus, I guess: unlike the title, labels stay visible no matter how one scrolls the PR / issue, and they are more easily searchable. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBAgAGBQJXh90aAAoJEPKpaDSJE9HYeFMP/3r+b6MP4VI+SLnPT6PeZdHU aVn9/bz4hMb4DtIB1adp6CBEdtxijg0Y2H6BgcmnoFcqhVO0yXquOtJmVfqQr44T zO8DY+v+eVBcw8KX5MduQt3jLq8fBXviFq0yu55bWYboQRKbUKrfzFwZFlZJ9gH7 AAdieX/26NK4RkFxePYn5dJeJ1EIX7RoRuIB8X5NPve6FA08eRUHvSicQN4Vpvey Xs+eiLcz+3pOHCu4hiERInu19lztoL5GmdC+cL3mq2A9qpKy9fEAWVRhU84VaDa1 86/jKXgoXfZt2wH7Wj/MC6Z8gXMutIyjcrjVyZEbPQe4zt5o5Vdv/M9nxk1iOnV3 sSqY72HQiiaWvwjWasv0F78LT0nKqt9+bq+aBHrF5PHd0epxInI7KQEScuB+BcaS aNNVZtSRRQhCEnO8MB6cedBv90sg2FVv8ITBNHac/Zn2ThljMJ8s90gHZZbC3T6/ uP0uvwS8aYzKJoTH5Mmxvt4m4vQCg+tintOwF8/nwN4y4kQFXZcCZqeb4l55XRAE INal/Khx0eHqd07D7BRZ/a1lKTDuyEuTifJNjZjr9fC704xplMTygJc/kuaTvMfN 4e30iKbMO4oJ3Oyrysr/2E81YlqBe9ZMGdkdBwvyYmGnIKXbmlsHHUQn1asRwF64 l5HJUWDAWxccJ8d83q0g =NdlU -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] The devguide is now hosted on GitHub
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/22/2016 04:04 PM, Brett Cannon wrote: > https://github.com/python/devguide > > I have also moved all issues over as well and hooked up Read The Docs > so that there's a mirror which is always up-to-date (vs. > docs.python.org/devguide which is on a cronjob). What is the RTD project name? Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBAgAGBQJXkos+AAoJEPKpaDSJE9HY6PAP/AzvI1diFpjjhgQARkmCSvrT MugaShX60PGQDUtTTVCmlZg0Ca6mWgbiaX8JS/kYQuc3SI2JIs+lD/mdCydWKYfx Gzks/rzaS60NkXZjb/yW7Vs+2wQo2EWHC/uzKRDGT7m0yijQW0WQaACgWEtSo0v3 6FzIyxQyYi1UVD10Iw7TWCvYxk2F33QXha5hOsq2N3Zs9Vopkj9p2KeViCxs4UuX VT2hZam/X6ZPkEkHlRkuZM4UpYM3Zt5+dmrODI5ieXjsUngvfcVhVvay33tStlH9 DJYGPgAWCzNkiScDCWk8+iXkLqJAQusVms6HbgQcToRj2ySbWdtn+EMFp9Y+baGl GBFQoiHhj1nw9yFf4pGgO4xRyvwc4vfTs7PJnZnOxLI7STaRL6L5TpXSuFGVN0Sw 6AumK4mzXidK4efpROUGmLcc3SjuB266jmYDPmNmrqKtHXTIycEgwIjSeWFrMXOE zxQ/TeKiAIr05np22LyXFmm64ryaZjoXqkPdo1fHh6rp456t3o2rkxk4ghuMH4xs IA4V/LBW1BlWr+4P+JIDP+vhyZ45J5SHKvX3OY1OaRDyWHHTEA7qSic6x6CKfUWv o7cr0Kx6ehdwmDUGMfzcGUCoWoNrydKlh0PM2UEAyX+e6RY/5sq1NiKRfrHrO17L Mznm6AZXZXi3D8MkEEDa =+fVX -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 3.6 dict becomes compact and gets a private version; and keywords become ordered
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/13/2016 02:11 PM, Sven R. Kunze wrote: > On 13.09.2016 19:59, MRAB wrote: >> The recommended way of dealing with features across different >> versions of Python is to check for them and see if they raise >> NameError or whatever, but I wonder if there would be any benefit to >> recording such things somewhere, e.g. sys.features['ordered_args'] >> returns True if arguments are passed in an ordered dict. > > Just to check: do people really that often change between Python > implementations? > > My personal experience with this kind of compatibility is that it is > rarely needed for large and complex programs. That is due to > deployment and testing issues (at least in our environment as we run > multiple Python services on a multitude of servers). *Lots* of library authors have to straddle Python versions: consumers of those libraries only get to pick and choose when their code is at the "leaf" of the dependency tree (the application). Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBAgAGBQJX2EOfAAoJEPKpaDSJE9HYkokP/j74MGBGt+JjcalETp54yJ5n zgun42oE8c+8rTl2gsnn+E7lipTZ9XW4e+/+XDAOBsb3VK3X344l4Wn1i1pfi9/n 1DXEJkO4rbvIOOI2pcsuVCHTLxcpafvKo0+sjVuXdbuBwWFS1OcSTXGoJ7UKi9yI NtmY16qIYLgNhbxRj5dysnFHtnBD9dnQTxs77QFGnu59nT8i+EI0BRqASMXTNhF3 3IZ13BqIIc0megaaSjfNt3BXaMSHEOpAjhes5ni6OEPPVuDk6XRQf705WcjY2S4H EKaArqJIwWHoLOO4gLiaFAa8x0+Vsl8nfGxgWFZFIPiZ0ALqcZ2YHg0GclUs8J4p eOPuLodc9GqtuyhbPctZLU2EbiGDexGS6GkIa3ESh0/WFaOKB5rt/26szHq/WWXE CGSq7QJssoiKfmdniSY1oa4n/1Q3N1PxZfv54YwnAPGy5SOYspFaWnCwORPRlH9s U2p8X61T5SGFouK3XNv8ZgswpH9bF51JBCJuXl9F1reL+4TpfD/0gHIUQLu34Ot/ 54zxtBB0h+FgnMZ62g+vp04d//0sw/BfsVElkjHi5ptcb+A9IAgjIfOWRDRtSzEx yOQ80dY3BPmknbYecdkYgJhlWke0FT6TOMYA/SVFd6IMol4hxPuDvgfvljRrZeJp Y3ilNxoz72TG5kHfEDbS =Xa3X -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Deprecate `from __future__ import unicode_literals`?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/16/2016 04:27 PM, Barry Warsaw wrote: > Getting rid of cruft like this is one of the more satisfying edits > when dropping Python 2 support. :) Ripping it out and replacing with explicit unicode literals is pretty satisfying when straddling, too. ;) Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBAgAGBQJYVF7+AAoJEPKpaDSJE9HYSF0P/Ax00KYJQpIQdr7U4vn3Sz6F CpAfxIxR4uuZJMNwzxl1sBmsJ0xvoO2aldGwbbOzlvlbP1km4MlLfRC/ZFwoKWs0 yDA5xiUrwUGDPME6IEtTzn7CCk5INP6avX2zLkZg6qMfJ9Cd0VJkcJGAXE6CtAwS swAEJcfeIhb+5gnyHHECLc6XC+LQPf6GHkD0im3ayACr73bMCvdHRYF7pJaZ/XWN 1WYbRlPup0//Ge0MbHAUdn8GwnEm+e2GB1roKEryaSBEHfhtDm1iKPjWeg/gic91 j76nTeQ0qepdjGjGAISiPersSPEW44bzXCSDLh6OfQAUtDqA9pWFbNfOtMkjuM89 +VRC606QinShzwVbmsTbVwl4VAmYqPg/BplteP81nV8uOrsRlFkNJ6oLqhsTM6eM lFSBGnwDnrP1URt5r2LGs6aKKmZb5aGdW7puYgaaNzrzD5uMW5Kr1B7cPOwP//rD Y37x4Cu5jq0v9K5yVEc4GbvBdCjgREAUxweS5xUwWoPxFEPcdJiGZqLeYzpV2Llm K+J+Wa91RdKUtW3G/k16te9QVA0HWFSLMi1+v8XD4xoe3dmktxZeWSa6sUWaDeDT gso1uABYrvssiNT9+iMLNXNtJ2o4ZytMp6P9uOIUkJWqval1jPzWFZzF5wJA98mI ebthSapz3wpZQe6+ab17 =frxy -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Constifying C API
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/18/2016 07:54 PM, Nick Coghlan wrote: > On 18 December 2016 at 18:31, Serhiy Storchaka > wrote: > >> Later I'm planning following changes: >> >> * Add the const qualifier to the result of functions that return >> references to internal representation of immutable objects, like >> PyBytes_AS_STRING() or PyUnicode_DATA(). While CPython internally >> can modify the content of immutable objets, this is very dangerous, >> because this can invalidates invariants and cached values. >> Third-party code shouldn't do this. >> >> * Add the const qualifier to the format field of Py_buffer. It is a >> reference to C string literal or to the content of bytes object. >> Mutating its content is an error. Only _testbuffer overuses the >> format field of internal Py_buffer object for owning a reference to >> allocated memory. But this is not leaked outside. >> >> What are you think about this? >> > > As long as it's on the default branch with appropriate notes in the C > porting section of the 3.7 What's New, turning these kinds of runtime > errors into compilation errors sounds like the right thing to do to > me. > > One key aspect from my perspective is that code that is updated to > correctly declare the destination storage as a const pointer will > still compile against the old API variants that return a mutable > pointer, so any problems this finds in third party code are likely to > be resolved for older 3.x releases as well. Agreed. Anything the compiler ralfs on after adding 'const' (where the actual target must be immutable) already had the fuse smoldering. FWIW I help maintain some *old* C extensions (fifteen+ years and counting), and am as likely to be affected as anyone. Tres - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBAgAGBQJYVz1oAAoJEPKpaDSJE9HYNc0P/2ZfDQeWmecy/deL4mqvLh42 iZuyyXoYmsEvHWgTL1gCOK3isUAKn5MMDAk79ezGkbmrmerxV0EVCrIsQMaCBuhY ypWxsPHa1nUpJpTuziHi452ETDq606nDgUXJnNUtR1xqVlFNpNskTYdexkxv4K5W E+ANwNvE+/YZN7t8KmIcR8pczRGhWJ5X67+etG0KlJ0mDR13RIpUZs7OfTFsXRi1 YHYgI1uKKkphB/KdPxeQfN4G5CgiRK3fJ8sQO2ojJKt3xMqPJcmGG0KIHZi0waXA Uqh+ukKE1tWDdBPYubv+4nlrtWQye6kX9gUu/gXYXM9C7h3u9B9otYXblNGqZAol q6+QfnSmOCZkGeaGw+Gwzz+B2yQcz4phuaz1AirtYUA66s0vbLuKi+SNiVei2gzn M/xd1HpZOxFVk/QkZYHlOW0k2F8o73ecWSONo1xTgi7pdjDrAALhbQ+7Z/dBHn0i 474VoRXcEqVwST87CqbEXyW82GexOppPGqi0jgeAFWJtb0HytuLv21l/h7XgX/TV lmrxGAh6VGl2FOIQolgSNKaVQHsxh2xDq8lL7hGgXuDcI4fD3d+p6bu3tpN6nXMA b4k0TAry7PfKASk0MJgU9aZCSFulDR8ghnx+nUte0OrDdd+nqaovtZcT1Y52glU/ FBw00PcU9+MWZ+zlQNfs =/M++ -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Translated Python documentation
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/22/2017 07:10 AM, Victor Stinner wrote: > Hi, > > I'm a member of the french #python-fr IRC channel on Freenode: it's > common to meet people who don't speak english and so are unable to > read the Python official documentation. Python wants to be widely > available, for all users, in any language: that's also why Python 3 > now allows any non-ASCII identifiers: > https://www.python.org/dev/peps/pep-3131/#rationale > > There are a least 3 groups of people who are translating the Python > documentation in their mother language (french, japanese, spanish). > They tried to make it more official, but their attempt didn't go far > yet. I'm writing this email to propose to officially support > translated versions of the documentation. > > For me, the most impotant point would be to give access to the > translated documentation from docs.python.org. For example, have a > dropdown list with available languages. > > IMHO a reference in this domain is PHP: PHP documentation is > translated to at least 10 languages. See for example the "Change > language: [...]" list at: > > http://php.net/echo > > I'm not asking you to take any technical decision here, I'm just > asking for an official general "support" of translated documentation. +1 for the idea. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBAgAGBQJYrawEAAoJEPKpaDSJE9HYevwP/0KsRu1KNkBGFVffA8WNBDqT khZta8AogUnvIkubNxDWvtMgo+UDgXdpW0D0/uCI5ON8O6TVeAQp8JB5giZkKt6e VSoXjPaD4sJJRjWCFj+z33DCu/HlVE5+qt60cRQ6kwWWKWm6Aoh+yiu1g0CDQIN0 miOmc+6rZWTptYUDYX3j/gq1W/XxiaEDIJTf9D8GUQ7YZA6AyTkzUm1o9OY8PJdg lSsTxkjuriQPLJq6IVXMZxOUPKgU/O9HLL9r3XfRqA/sIle6pz6z6qKIQOHj246E lKiSXwm2Gik+XrIk0YfIG+ZezlWJuRyyA+7wksxQmX/Azl85iQ/Nb5/zwVMTfpF1 NIT0++bpefM5X/Y7CLusupNIQ90k5dSMjX9uPOBoK/ZIJ7I6QglBVxr97CHx1FCn lJ4brOkBnGCtz9mJ50FgM4YqYuUUWjw8mZxpjv5URl8ouPdZnhmuWmiRJLgezmbV n0uqjr9XvEdXEYidRzL39LAWcERJIj1CfyyCgDISYw8eaZsrn29lrk0F8x17XAIP Z0iIF4cYg0Z1oXqmWelzljDyo66GIMybof3R2pHKCiPlfZeE3b+AwgU2eyI+6lnj iVfQi5ok4XuYMydmJhjfWbmz8xb0jkqQ7un3TRb6w8MFOS1WxxYAsVJnesA6Jk3c g4leycwmSg9dTQ/TSRZj =6/rU -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Attention Bazaar mirror users
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martin v. Löwis wrote: >> I didn't say "from source", I said "from a VCS checkout". If using a >> *specific* recent official release of a core tool is bureaucratically >> infeasible, it would IMO be very unusual if you're allowed to checkout >> and build arbitrary versions of Python, rather than using a version >> provided by your bureaucrats. >> >> The number of people whose job is *specifically* developing Python, or >> developing code that depends on bleeding-edge Python, in such an >> environment is surely very small. > > This completely contradicts with my experience. In a university > environment, students regularly check out software from the source > repository, modify it, and build it, just to learn something by doing > so. Yet, in such an environment, they have little control over their > systems - they cannot install software themselves, but have to ask > the university bureaucrats (which often reject such wishes, unless > they come from a teacher - and often even in that case). > > There is no problem with people building their own versions of Python, > though - they do so in their home directories, and OS security > mechanisms prevent them from doing harm to other users. Wouldn't such hypothetical core Python developers be able to build and run their own local copy of bzr, using that self-compiled Python? Let's not strain at gnats and swallow camels here. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJoD2c+gerLs4ltQ4RAjglAJ9fgoSD0g9jJm8Kw/Z2PBvyXKYIWQCeL+Xa lybDHEZyjZxG21inSFsn1W0= =d02o -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Attention Bazaar mirror users
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Paul Moore wrote: > 2009/2/21 Barry Warsaw : >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> On Feb 21, 2009, at 4:11 PM, Paul Moore wrote: >> >>> PS Just for my own information, am I correct in thinking that it is >>> *only* Bazaar in the (D)VCS world that has this problem, to any real >>> extent? I know old Mercurial clients can interact with newer servers >>> (ie, the wire protocol hasn't changed), I'm fairly sure that older >>> Subversion clients can talk to newer servers (at least, I've never >>> cared what client version I'm running). I've not heard of this type of >>> discussion around Git (but my experience is limited). But Bazaar seems >>> very prone to this "upgrade the server and the clients need to be >>> upgraded too" cycle. >> That's not what we're talking about. This is a case of older clients not >> understanding a newer repository format. > > Sorry, I'm confused. Isn't that what I said? Clients (who still use > the - older - version they have at the moment) needing to upgrade to > be able to interact with the public repository (server) if that > repository is upgraded to a newer version? When you say "repository" > and I say "server", are we not discussing the same thing (the Bazaar > branches hosted at code.python.org)? This has been true for a number of cases over the years: whether the "repostiory format", or the wire protocol, sometimes changes which materially *improve* the user's experience may require upgrading the client on the user's machine. In the case of SVN, upgrading to 1.5 gets vastly better merging support; in the case ob bzr, the win is performance when working against a large tree. Given that all the DVCS support is experimental at this point, nobody is being *blocked* from hacking on the Python core by Barry's proposed chnage. He was trying to find out if *real* users of the bzr tree would be hurt by the repository format upgrade, rather than hypothetical ones. AFAICS, no real user (one already using bzr to work with the Python tree) has objected. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJoKaz+gerLs4ltQ4RAg4XAJ9zP0HU0S8xeaHsThxJ9/MJgpbztQCeINLH ar5pu9gP3tXdgHtOf3HGyWU= =4XLm -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Distutils in PEP 291
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tarek Ziadé wrote: > Hello, > > If no one objects, I would like to: > > - put Distutils back into PEP 291 for Python 2.3 compatibility > - fix the two issues that prevent the current trunk to run with Python > 2.3 to 2.5 (see http://bugs.python.org/issue5052 and the patch I > worked on) +1. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJp1QA+gerLs4ltQ4RAirAAJ99FomyrgYELjDITGBUtbmKtKlKOQCdHSjz LsAgd1PFZFyvTgdaIMkw4/o= =MKhZ -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] asyncore fixes in Python 2.6 broke Zope's version of medusa
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tres Seaver wrote: > Guido van Rossum wrote: >> On Wed, Oct 8, 2008 at 6:39 PM, Bill Janssen wrote: >>> Josiah Carlson wrote: >>> >>>> But yes, zope needs to be changed to reflect the updated >>>> asyncore/asynchat semantics. Trust me; it's faster, cleaner, and >>>> easier to use now. >>> Just for completeness, I built a fresh 2.6, installed Medusa (from >>> http://www.amk.ca/python/code/medusa.html), and it runs just fine (well, >>> as well as it does on 2.5, anyway). I think this is a Zope issue. >> Way back in the day, Zope monkeypatched whole parts of asyncore, >> replacing them with some of its own code. If that's still the case, >> this breakage should be no surprise. > > Zope has been hooking the 'asyncore.loop' function (wrapping it in order > to add a "clean shutdown' flog) since 2001 at least (the 2.5 branch is > the earliest checkout I have, and it was branched in early January 2002). > > Zope also began patched asyncore's logging functions in 2.7, and later > updated that patch to make the logger use the stdlib 'logging' module. > > I think the change we need to make (in ZServer/medusa/http_server.py) is > to emulate the new 'writeable' implementation in asynchat, at least when > running under 2.6. > > Zope's 'ZServer.medusa.http_server.http_request.writable()' > implementation is:: > > def writable (self): > # this is just the normal async_chat 'writable', > # here for comparison > return self.ac_out_buffer or len(self.producer_fifo) > > > The Python 2.5 asynchat.asynchat.writable does:: > > def writable (self): > "predicate for inclusion in the writable for select()" > # return len(self.ac_out_buffer) or len(self.producer_fifo) or > # (not self.connected) > # this is about twice as fast, though not as clear. > return not ( > (self.ac_out_buffer == '') and > self.producer_fifo.is_empty() and > self.connected > ) > > The Python 2.6 asynchat.asynchat.writable now does:: > > def writable (self): > "predicate for inclusion in the writable for select()" > return self.producer_fifo or (not self.connected) > > > medusa 0.5.4's medusa.http_server.http_request doesn't override > 'writable', but it does have a broken 'writeable_for_proxy': > > > def writable_for_proxy (self): > # this version of writable supports the idea of a 'stalled' > # producer > # [i.e., it's not ready to produce any output yet] This is > # needed by > # the proxy, which will be waiting for the magic combination of > # 1) hostname resolved > # 2) connection made > # 3) data available. > if self.ac_out_buffer: > return 1 > elif len(self.producer_fifo): > p = self.producer_fifo.first() > if hasattr (p, 'stalled'): > return not p.stalled() > else: > return 1 *crickets*. The 2.6 version of asyncore *also* breaks supervisord, which does *not* use Zope's medusa: it uses medusa 0.5.4. How is anybody supposed to write a package which sits atop a library like asyncore in a fashion portable across Python versions? The changes to the implementation in 2.6 (there is no real API) can't be reconciled, AFAICT. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJrZG0+gerLs4ltQ4RAnsmAJ9v/vPkHgE3AdP5ngVuYaKlxDGhJACgsCi2 3awbUffi2BU41qQgd6eJV18= =WBt6 -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] asyncore fixes in Python 2.6 broke Zope's version of medusa
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Guido van Rossum wrote: > On Tue, Mar 3, 2009 at 12:23 PM, Tres Seaver wrote: >> How is anybody supposed to >> write a package which sits atop a library like asyncore in a fashion >> portable across Python versions? The changes to the implementation in >> 2.6 (there is no real API) can't be reconciled, AFAICT. > > This seems to be the crux of the problem with asyncore, ever since it > was added to the stdlib -- there's no real API, so every change > potentially breaks something. I wish we could start over with a proper > design under a new name. Maybe packages requiring asyncore > functionality should just copy the version of asyncore they like into > their own three and stick with that. That was the very solution Chris came up with earlier today: "stick a fork in it, its done!" Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJraty+gerLs4ltQ4RAjBSAJ4niecZJusKY4XiioJ18mdhdMixxQCfWvcQ Dwkh1ZBuxtGRbhUI4qy96Sc= =ms0I -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
