Re: [Python-Dev] subclassing builtin data structures

On Fri, Feb 13, 2015 at 06:03:35PM -0500, Neil Girdhar wrote: I personally don't think this is a big enough issue to warrant any changes, but I think Serhiy's solution would be the ideal best with one additional parameter: the caller's type. Something like def __make_me__(self, cls, *args,

Re: [Python-Dev] subclassing builtin data structures

On Sat, Feb 14, 2015 at 01:26:36PM -0500, Alexander Belopolsky wrote: On Sat, Feb 14, 2015 at 7:23 AM, Steven D'Aprano st...@pearwood.info wrote: Why can't int, str, list, tuple etc. be more like datetime? They are. In all these types, class methods call subclass constructors

Re: [Python-Dev] boxing and unboxing data types

On Mon, Mar 09, 2015 at 09:52:01AM -0400, Neil Girdhar wrote: Here is a list of methods on int that should not be on IntFlags in my opinion (give or take a couple): __abs__, __add__, __delattr__, __divmod__, __float__, __floor__, __floordiv__, __index__, __lshift__, __mod__, __mul__,

Re: [Python-Dev] Tunning binary insertion sort algorithm in Timsort.

On Sun, Mar 08, 2015 at 10:57:30PM -0700, Ryan Smith-Roberts wrote: I suspect that you will find the Python community extremely conservative about any changes to its sorting algorithm, given that it took thirteen years and some really impressive automated verification software to find this

Re: [Python-Dev] PEP 488: elimination of PYO files

On Wed, Mar 11, 2015 at 05:34:10PM +, Brett Cannon wrote: I have a poll going on G+ to see what people think of the various proposed file name formats at https://plus.google.com/u/0/+BrettCannon/posts/fZynLNwHWGm . Feel free to vote if you have an opinion. G+ hates my browser and won't

Re: [Python-Dev] PEP 488: elimination of PYO files

On Fri, Mar 06, 2015 at 08:00:20PM -0500, Ron Adam wrote: Have you considered doing this by having different magic numbers in the .pyc file for standard, -O, and -O0 compiled bytecode files? Python already checks that number and recompiles the files if it's not what it's expected to be.

Re: [Python-Dev] boxing and unboxing data types

On Sun, Mar 08, 2015 at 08:31:30PM -0700, Ethan Furman wrote: When data is passed from Python to a native library (such as in an O/S call), how does the unboxing of data types occur? [...] So the real question: anywhere in Python where an int is expected (for lower-level API work), but not

Re: [Python-Dev] Type hints -- a mediocre programmer's reaction

On Mon, Apr 20, 2015 at 11:34:51PM +0100, Harry Percival wrote: exactly. yay stub files! we all agree! everyone loves them! Not even close. -- Steve ___ Python-Dev mailing list Python-Dev@python.org

Re: [Python-Dev] Type hints -- a mediocre programmer's reaction

On Mon, Apr 20, 2015 at 07:30:39PM +0100, Harry Percival wrote: Hi all, tldr; type hints in python source are scary. Would reserving them for stub files be better? No no no, a thousand times no it would not! Please excuse my extreme reaction, but over on the python-list mailing list

Re: [Python-Dev] Type hints -- a mediocre programmer's reaction

On Mon, Apr 20, 2015 at 02:41:06PM -0400, Barry Warsaw wrote: On Apr 20, 2015, at 07:30 PM, Harry Percival wrote: tldr; type hints in python source are scary. Would reserving them for stub files be better? I think so. I think PEP 8 should require stub files for stdlib modules and

Re: [Python-Dev] Type hints -- a mediocre programmer's reaction

On Thu, Apr 23, 2015 at 03:25:30PM +0100, Harry Percival wrote: lol @ the fact that the type hints are breaking github's syntax highlighter :) That just tells us that Github's syntax highlighter has been broken for over five years. Function annotations go back to Python 3.0, more than five

Re: [Python-Dev] Type hints -- a mediocre programmer's reaction

On Tue, Apr 21, 2015 at 11:56:15AM +0100, Rob Cliffe wrote: (Adding a type hint that restricted the argument to say a sequence of numbers turns out to be a mistake. Let's find out how big a mistake it is with an test run. py def sorter(alist: List[int]) - List[int]: ... return

Re: [Python-Dev] Type hints -- a mediocre programmer's reaction

On Tue, Apr 21, 2015 at 01:25:34PM +0100, Chris Withers wrote: Anyway, I've not posted much to python-dev in quite a while, but this is a topic that I would be kicking myself in 5-10 years time when I've had to move to Javascript or insert new language here because everyone else has

Re: [Python-Dev] Type hints -- a mediocre programmer's reaction

On Tue, Apr 21, 2015 at 03:08:27PM +0200, Antoine Pitrou wrote: On Tue, 21 Apr 2015 22:47:23 +1000 Steven D'Aprano st...@pearwood.info wrote: Ironically, type hinting will *reduce* the need for intrusive, anti-duck-testing explicit calls to isinstance() at runtime: It won't, since

Re: [Python-Dev] typeshed for 3rd party packages

On Wed, Apr 22, 2015 at 11:26:14AM -0500, Ian Cordasco wrote: On a separate thread Cory provided an example of what the hints would look like for *part* of one function in the requests public functional API. While our API is outwardly simple, the values we accept in certain cases are actually

Re: [Python-Dev] async/await in Python; v2

On Thu, Apr 23, 2015 at 01:51:52PM -0400, Barry Warsaw wrote: Why async def and not def async? My concern is about existing tools that already know that def as the first non-whitespace on the line starts a function/method definition. Think of a regexp in an IDE that searches backwards from

Re: [Python-Dev] async/await in Python; v2

On Fri, Apr 24, 2015 at 09:32:51AM -0400, Barry Warsaw wrote: On Apr 24, 2015, at 11:17 PM, Steven D'Aprano wrote: It seems to me that tools that search for r^\s*def\s+spam\s*\( are They would likely search for something like r^\s*def\s+[a-zA-Z0-9_]+ which will hit def async spam

Re: [Python-Dev] Type hints -- a mediocre programmer's reaction

On Sat, Apr 25, 2015 at 02:05:15AM +0100, Ronan Lamy wrote: * Hints have no run-time effect. The interpreter cannot assume that they are obeyed. I know what you mean, but just for the record, annotations are runtime inspectable, so people can (and probably have already started) to write

Re: [Python-Dev] typeshed for 3rd party packages

On Fri, Apr 24, 2015 at 03:44:45PM +0100, Cory Benfield wrote: On 24 April 2015 at 15:21, Steven D'Aprano st...@pearwood.info wrote: If the type hints are wrong, there are two errors: false positives, when code which should be allowed is flagged as a type error; and false negatives, when

Re: [Python-Dev] Type hints -- a mediocre programmer's reaction

On Mon, Apr 20, 2015 at 08:37:28PM -0700, Guido van Rossum wrote: On Mon, Apr 20, 2015 at 4:41 PM, Jack Diederich jackd...@gmail.com wrote: Twelve years ago a wise man said to me I suggest that you also propose a new name for the resulting language The barrage of FUD makes me feel like

Re: [Python-Dev] Type hints -- a mediocre programmer's reaction

On Tue, Apr 21, 2015 at 03:51:05PM +0100, Cory Benfield wrote: On 21 April 2015 at 15:31, Chris Angelico ros...@gmail.com wrote: Granted, there are some vague areas - how many functions take a file-like object, and are they all the same? - but between MyPy types and the abstract base

Re: [Python-Dev] What's missing in PEP-484 (Type hints)

On Thu, Apr 30, 2015 at 01:41:53PM +0200, Dima Tisnek wrote: # Syntactic sugar Beautiful is better than ugly, thus nice syntax is needed. Current syntax is very mechanical. Syntactic sugar is needed on top of current PEP. I think the annotation syntax is beautiful. It reminds me of Pascal.

Re: [Python-Dev] PEP 492 quibble and request

On Wed, Apr 29, 2015 at 06:12:37PM -0700, Guido van Rossum wrote: On Wed, Apr 29, 2015 at 5:59 PM, Nick Coghlan ncogh...@gmail.com wrote: On 30 April 2015 at 10:21, Ethan Furman et...@stoneleaf.us wrote: From the PEP: Why not a __future__ import __future__ imports are

Re: [Python-Dev] PEP 492 quibble and request

On Wed, Apr 29, 2015 at 07:31:22PM -0700, Guido van Rossum wrote: Ah, but here's the other clever bit: it's only interpreted this way *inside* a function declared with 'async def'. Outside such functions, 'await' is not a keyword, so that grammar rule doesn't trigger. (Kind of similar to the

Re: [Python-Dev] PEP 492: async/await in Python; version 4

On Fri, May 01, 2015 at 09:24:47PM +0100, Arnaud Delobelle wrote: I'm not convinced that allowing an object to be both a normal and an async iterator is a good thing. It could be a recipe for confusion. In what way? I'm thinking that the only confusion would be if you wrote async for

Re: [Python-Dev] Keyword-only parameters

On Tue, Apr 14, 2015 at 01:40:40PM -0400, Eric V. Smith wrote: But, I don't see a lot of keyword-only parameters being added to stdlib code. Is there some position we've taken on this? Barring someone saying stdlib APIs shouldn't contain keyword-only params, I'm inclined to make numeric_owner

Re: [Python-Dev] PEP 8 update

On Tue, Apr 07, 2015 at 03:11:30AM +0100, Rob Cliffe wrote: As a matter of interest, how far away from mainstream am I in preferring, *in this particular example* (obviously it might be different for more complicated computation), def foo(x): return math.sqrt(x) if x = 0 else

Re: [Python-Dev] PEP 8 update

On Tue, Apr 07, 2015 at 08:47:25AM -0400, Ben Hoyt wrote: My own preference would be: def foo(x): if x = 0: return math.sqrt(x) return None Kind of getting into the weeds here, but I would always invert this to return errors early, and keep the

Re: [Python-Dev] Importance of async keyword

On Thu, Jun 25, 2015 at 05:55:53PM +0200, Sven R. Kunze wrote: On 25.06.2015 04:16, Steven D'Aprano wrote: On Wed, Jun 24, 2015 at 11:21:54PM +0200, Sven R. Kunze wrote: [...] What is the difference of a function (no awaits) or an awaitable ( 1 awaits) from an end-user's perspective (i.e

Re: [Python-Dev] Importance of async keyword

On Wed, Jun 24, 2015 at 11:21:54PM +0200, Sven R. Kunze wrote: Thanks, Yury, for you quick response. On 24.06.2015 22:16, Yury Selivanov wrote: Sven, if we don't have 'async def', and instead say that a function is a *coroutine function* when it has at least one 'await' expression, then

Re: [Python-Dev] Unicode 8.0 and 3.5

On Fri, Jun 19, 2015 at 01:55:07AM +0100, MRAB wrote: On 2015-06-19 00:56, Steven D'Aprano wrote: At the very least, there is a change to the casefolding algorithm. Cherokee was classified as unicameral but is now considered bicameral (two cases, like English). Unusually, case-folding

Re: [Python-Dev] Unicode 8.0 and 3.5

On Thu, Jun 18, 2015 at 08:34:14PM +0100, MRAB wrote: On 2015-06-18 19:33, Larry Hastings wrote: On 06/18/2015 11:27 AM, Terry Reedy wrote: Unicode 8.0 was just released. Can we have unicodedata updated to match in 3.5? What does this entail? Data changes, code changes, both? It

Re: [Python-Dev] What were the complaints of binary code programmers that not accept Assembly?

Hi Françai, This list is for the development of the Python programming language, not Fortran, assembly, or discussions about the early history of programming. Possibly Stackoverflow or one of their related sites might be a better place to ask. Or you could ask on the python-l...@python.org

Re: [Python-Dev] Single-file Python executables (was: Computed Goto dispatch for Python 2)

On Thu, May 28, 2015 at 01:20:06PM -0400, Donald Stufft wrote: I think it’s an issue for all platforms, even when there is a system Python that can be used. Here’s why: * Even on Linux systems Python isn’t always a guaranteed thing to be installed,   for instance Debian works just fine

Re: [Python-Dev] Single-file Python executables (was: Computed Goto dispatch for Python 2)

On Thu, May 28, 2015 at 05:38:49PM +0100, Paul Moore wrote: I suspect single file executables just aren't viewed as a desirable solution on Unix. More of an anti-pattern than a pattern. A single file executable means that when you have a security update, instead of patching one library, you

Re: [Python-Dev] Single-file Python executables (was: Computed Goto dispatch for Python 2)

On Fri, May 29, 2015 at 07:08:43AM +1000, Nick Coghlan wrote: On 29 May 2015 05:25, Chris Barker chris.bar...@noaa.gov wrote: OK, I'm really confused here: 1) what the heck is so special about go all of a sudden? People have been writing and deploying single file executables built with

Re: [Python-Dev] Importance of async keyword

On Sun, Jul 05, 2015 at 11:50:00PM +0200, Sven R. Kunze wrote: Seems like we stick to this example once again. So, let me get this straight: 1) I can add, subtract, multiply and divide real numbers. 2) I can add, subtract, multiply and divide complex numbers. I don't think that this is a

Re: [Python-Dev] updating ensurepip to include wheel

On Sun, Aug 16, 2015 at 10:52:00AM -0400, Donald Stufft wrote: So what is the benefit of including wheel with ensurepip? pip has an optional dependency on wheel, if you install that optional dependency than you’ll get the implicit wheel cache enabled by default which can drastically

Re: [Python-Dev] updating ensurepip to include wheel

On Sun, Aug 16, 2015 at 02:17:09PM +0100, Paul Moore wrote: Sorry I'm late to this, but I would very much like to see wheel installed with ensurepip on at least Windows. I seem to be missing something critical to this entire discussion. As I understand it, ensurepip is *only* intended to

Re: [Python-Dev] who must makes FOR loop quicker

On Wed, Aug 05, 2015 at 06:25:07PM +0300, John Doe wrote: To pass by reference or by copy of - that is the question from hamlet. (hamlet - a community of people smaller than a village python3.4-linux64) [snip question] John, you have already posted this same question to the tutor list, where

Re: [Python-Dev] PEP 498 f-string: please remove the special case for spaces

On Tue, Aug 11, 2015 at 09:51:56PM +1000, Chris Angelico wrote: On Tue, Aug 11, 2015 at 5:08 PM, Cameron Simpson c...@zip.com.au wrote: On 11Aug2015 18:07, Greg Ewing greg.ew...@canterbury.ac.nz wrote: Cameron Simpson wrote: To illustrate, there's a consumer rights TV snow here with a

Re: [Python-Dev] PEP-498: Literal String Formatting

On Sun, Aug 09, 2015 at 06:14:18PM -0700, David Mertz wrote: [...] That said, there *is* one small corner where I believe f-strings add something helpful to the language. There is no really concise way to spell: collections.ChainMap(locals(), globals(), __builtins__.__dict__). I think

Re: [Python-Dev] PEP-498: Literal String Formatting

On Sun, Aug 09, 2015 at 06:54:38PM -0700, David Mertz wrote: Which brought to mind a certain thought. While I don't like: f'My name is {name}, my age next year is {age+1}' I wouldn't have any similar objection to: 'My name is {name}, my age next year is {age+1}'.scope_format()

Re: [Python-Dev] PEP-498: Literal String Formatting

On Mon, Aug 10, 2015 at 09:23:15PM +0200, Guido van Rossum wrote: [...] Anyway, this generalization from print() is why I want arbitrary expressions. Wouldn't it be silly if we introduced print() today and said we don't really like to encourage printing complicated expressions, but maybe we

Re: [Python-Dev] Status on PEP-431 Timezones

On Mon, Jul 27, 2015 at 10:54:02AM +0200, Lennart Regebro wrote: On Mon, Jul 27, 2015 at 10:47 AM, Paul Moore p.f.mo...@gmail.com wrote: I'm confused by your position. If it's 7am on the clock behind me, right now, then how (under the model proposed by the PEP) do I find the datetime value

Re: [Python-Dev] How far to go with user-friendliness

On Tue, Jul 14, 2015 at 11:09:50PM +1000, Nick Coghlan wrote: Dima's right that the main defence against this kind of error is actually linters and IDEs, but detecting this particular one at runtime is harmless, so there's no particular reason *not* to do it when it's possible to construct a

Re: [Python-Dev] How far to go with user-friendliness

On Tue, Jul 14, 2015 at 02:06:14PM +0200, Dima Tisnek wrote: https://bugs.python.org/issue21238 introduces detection of missing/misspelt mock.assert_xxx() calls on getattr level in Python 3.5 Michael and Kushal are of the opinion that assret is a common typo of assert and should be

[Python-Dev] Why wasn't I consulted [was How far to go with user-friendliness]

On Wed, Jul 15, 2015 at 10:59:50AM +1000, Nick Coghlan wrote: Remember folks, Why wasn't I consulted?!?!?!? is one of the more obnoxious behavours we can inflict on fellow open source maintainers giving us the gift of their time and energy. Nick makes a good point, but it's more complicated

Re: [Python-Dev] How far to go with user-friendliness

On Fri, Jul 17, 2015 at 04:37:04PM +1000, Nick Coghlan wrote: The specific typo that is checked is the only one that changes the spelling without also changing the overall length and shape of the word. I don't think your comment above is correct. assert = aasert aseert azzert essert

Re: [Python-Dev] [Python-checkins] Daily reference leaks (d7e490db8d54): sum=61494

On Wed, Oct 21, 2015 at 10:10:56AM -0700, Ethan Furman wrote: > On 10/21/2015 08:53 AM, Random832 wrote: > > >If a pure python class can cause a reference leak, doesn't that mean it > >is only a symptom rather than the real cause? Or is it that the use of > >@object.__new__ is considered "too

Re: [Python-Dev] Support of UTF-16 and UTF-32 source encodings

On Sat, Nov 14, 2015 at 09:19:37PM +0200, Serhiy Storchaka wrote: > If the support of UTF-16 and UTF-32 is planned, I'll take this to > attention during refactoring. But in many places besides the tokenizer > the ASCII compatible encoding of source files is expected. Perhaps another way of

Re: [Python-Dev] If you shadow a module in the standard library that IDLE depends on, bad things happen

CC'ing Python-Ideas. Follow-ups to Python-Ideas please. On Thu, Oct 29, 2015 at 09:22:15PM -0400, Terry Reedy wrote: > Leaving IDLE aside, the reason '' is added to sys.path is so that people > can import their own modules. This is very useful. Shadowing is the > result of putting it at the

Re: [Python-Dev] Second milestone of FAT Python

On Wed, Nov 04, 2015 at 09:50:33AM +0100, Victor Stinner wrote: > Hi, > > I'm writing a new "FAT Python" project to try to implement optimizations in > CPython (inlining, constant folding, move invariants out of loops, etc.) > using a "static" optimizer (not a JIT). For the background, see the

Re: [Python-Dev] type(obj) vs. obj.__class__

On Sun, Oct 18, 2015 at 05:35:14PM -0700, David Mertz wrote: > In any case, redefining a method in a certain situation feels a lot less > magic to me than redefining .__class__ That surprises me greatly. As published in the Python Cookbook[1], there is a one-to-one correspondence between the

Re: [Python-Dev] type(obj) vs. obj.__class__

On Mon, Oct 19, 2015 at 11:41:44AM +1100, Chris Angelico wrote: > What does this provide that collections.deque(maxlen=size_max) > doesn't? I'm a little lost. The Ringbuffer recipe predates deque by quite a few years. These days I would consider it only useful in a pedagogical context, giving a

[Python-Dev] PEP 506 secrets module

Hi, As extensively discussed on Python-Ideas, the secrets module and PEP 506 is (I hope) ready for pronouncement. https://www.python.org/dev/peps/pep-0506/ There is code and tests here: https://bitbucket.org/sdaprano/secrets or you can run hg clone

Re: [Python-Dev] PEP 506 secrets module

On Fri, Oct 16, 2015 at 08:57:24AM +0200, Victor Stinner wrote: > Hi, > > I like the PEP. IMHO it's a better solution than using a CPRNG for > random by default. > > I suggest to raise an error if token_bytes(n) if calls with n < 16 > bytes (128 bits). Well, I'm not sure that 16 is the good

Re: [Python-Dev] type(obj) vs. obj.__class__

On Sat, Oct 17, 2015 at 03:45:19PM -0600, Eric Snow wrote: > In a recent tracker issue about OrderedDict [1] we've had some > discussion about the use of type(od) as a replacement for > od.__class__. [...] > The more general question of when we use type(obj) vs. obj.__class__ > applies to both

Re: [Python-Dev] PEP 506 secrets module

On Fri, Oct 16, 2015 at 06:35:14PM +0300, Serhiy Storchaka wrote: > I suggest to add only randrange(). randint() is historical artefact, we > shouldn't repeat this mistake in new module. The secrets module is not > good way to generate dice rolls. In most other cases you need to > generate

Re: [Python-Dev] PEP 506 secrets module

On Sat, Oct 17, 2015 at 03:26:46AM +1100, Steven D'Aprano wrote: > On Fri, Oct 16, 2015 at 06:35:14PM +0300, Serhiy Storchaka wrote: > > > I suggest to add only randrange(). randint() is historical artefact, we > > shouldn't repeat this mistake in new module. The secrets modul

Re: [Python-Dev] PEP 0484 - the Numeric Tower

On Tue, Oct 13, 2015 at 04:37:43PM -0700, Raymond Hettinger wrote: > We could have (and still could) make the choice to always coerce to > decimal (every float is exactly representable in decimal). Further, > any decimal float or binary float could be losslessly coerced to a > Fraction, but

Re: [Python-Dev] Rationale behind lazy map/filter

On Tue, Oct 13, 2015 at 11:26:09AM -0400, Random832 wrote: > "R. David Murray" writes: > > > On Tue, 13 Oct 2015 14:59:56 +0300, Stefan Mihaila > > wrote: > >> Maybe it's just python2 habits, but I assume I'm not the only one > >> carelessly

Re: [Python-Dev] Python Language Reference has no mention of list comÃprehensions

On Thu, Dec 03, 2015 at 09:25:53AM -0800, Andrew Barnert via Python-Dev wrote: > > On Dec 3, 2015, at 08:15, MRAB wrote: > > > >>> On 2015-12-03 15:09, Random832 wrote: > >>> On 2015-12-03, Laura Creighton wrote: > >>> Who came up with the word

Re: [Python-Dev] Idea: Dictionary references

On Thu, Dec 17, 2015 at 12:53:13PM +0100, Victor Stinner quoted: > 2015-12-17 11:54 GMT+01:00 Franklin? Lee : > > Each function keeps an indirect, automagically updated > > reference to the current value of the names they use, Isn't that a description of

Re: [Python-Dev] Idea: Dictionary references

On Thu, Dec 17, 2015 at 09:30:24AM -0800, Andrew Barnert via Python-Dev wrote: > On Dec 17, 2015, at 07:38, Franklin? Lee > wrote: > > > > The nested dictionaries are only for nested scopes (and inner > > functions don't create nested scopes). Nested scopes will

Re: [Python-Dev] PEP 467: Minor API improvements to bytes, bytearray, and memoryview

On Wed, Jun 08, 2016 at 10:04:08AM +0200, Victor Stinner wrote: > It's common that users complain that Python core developers like > breaking the compatibility at each release. No more common as users complaining that Python features are badly designed and crufty and should be fixed. Whatever

Re: [Python-Dev] PEP: Ordered Class Definition Namespace

On Tue, Jun 07, 2016 at 11:39:06AM -0700, Eric Snow wrote: > On Tue, Jun 7, 2016 at 11:32 AM, Terry Reedy wrote: > > On 6/7/2016 1:51 PM, Eric Snow wrote: > > > >> Note: just to be clear, this PEP is *not* about changing > > > >> ``type.__dict__`` to ``OrderedDict``. > > > > By

Re: [Python-Dev] PEP 467: Minor API improvements to bytes, bytearray, and memoryview

On Wed, Jun 08, 2016 at 02:17:12AM +0300, Paul Sokolovsky wrote: > Hello, > > On Tue, 07 Jun 2016 15:46:00 -0700 > Ethan Furman wrote: > > > On 06/07/2016 02:33 PM, Paul Sokolovsky wrote: > > > > >> This PEP proposes to deprecate that behaviour in Python 3.6, and > > >>

Re: [Python-Dev] Stop using timeit, use perf.timeit!

On Sat, Jun 11, 2016 at 07:43:18PM -0400, Random832 wrote: > On Fri, Jun 10, 2016, at 21:45, Steven D'Aprano wrote: > > If you express your performances as speeds (as "calculations per > > second") then the harmonic mean is the right way to average them. > > T

Re: [Python-Dev] Stop using timeit, use perf.timeit!

On Fri, Jun 10, 2016 at 01:13:10PM +0200, Victor Stinner wrote: > Hi, > > Last weeks, I made researchs on how to get stable and reliable > benchmarks, especially for the corner case of microbenchmarks. The > first result is a serie of article, here are the first three: Thank you for this! I am

Re: [Python-Dev] Stop using timeit, use perf.timeit!

On Fri, Jun 10, 2016 at 05:07:18PM +0200, Victor Stinner wrote: > I started to work on visualisation. IMHO it helps to understand the problem. > > Let's create a large dataset: 500 samples (100 processes x 5 samples): > --- > $ python3 telco.py --json-file=telco.json -p 100 -n 5 > --- > >

Re: [Python-Dev] BDFL ruling request: should we block forever waiting for high-quality random bits?

On Thu, Jun 09, 2016 at 12:39:00PM -0400, Donald Stufft wrote: > There are three options for what do with os.urandom by default: > > * Allow it to silently return data that may or may not be > cryptographically secure based on what the state of the urandom pool > initialization looks like.

Re: [Python-Dev] BDFL ruling request: should we block forever waiting for high-quality random bits?

On Thu, Jun 09, 2016 at 12:54:31PM -0400, Ben Leslie wrote: > I think an exception is much easier for a user to deal with from a > practical point of view. Trying to work out why a process has hung is > obviously possible, but not necessarily easy. > > Having a process crash due to an exception

Re: [Python-Dev] Stop using timeit, use perf.timeit!

On Sat, Jun 11, 2016 at 12:06:31AM +0200, Victor Stinner wrote: > > Victor if you could calculate the sample skewness of your results I think > > that would be very interesting! > > I'm good to copy/paste code, but less to compute statistics :-) Would > be interesed to write a pull request, or

Re: [Python-Dev] Stop using timeit, use perf.timeit!

On Fri, Jun 10, 2016 at 11:22:42PM +0200, Victor Stinner wrote: > 2016-06-10 20:47 GMT+02:00 Meador Inge : > > Apologies in advance if this is answered in one of the links you posted, but > > out of curiosity was geometric mean considered? > > > > In the compiler world this is a

Re: [Python-Dev] BDFL ruling request: should we block forever waiting for high-quality random bits?

On Thu, Jun 09, 2016 at 07:52:31PM -0700, Nikolaus Rath wrote: > On Jun 09 2016, Guido van Rossum wrote: > > I don't think we should add a new function. I think we should convince > > ourselves that there is not enough of a risk of an exploit even if > > os.urandom() falls back.

Re: [Python-Dev] BDFL ruling request: should we block forever waiting for high-quality random bits?

On Fri, Jun 10, 2016 at 01:06:45PM -0700, Larry Hastings wrote: > > On 06/10/2016 01:01 PM, David Mertz wrote: > >So yes, I think 3.5.2 should restore the 2.6-3.4 behavior of os.urandom(), > > That makes... five of us I think ;-) (Larry Guido Barry Tim David) > > > >and the NEW APIs in secrets

Re: [Python-Dev] BDFL ruling request: should we block forever waiting for high-quality random bits?

On Fri, Jun 10, 2016 at 11:42:40AM -0700, Chris Jerdonek wrote: > And going back to Larry's original e-mail, where he said-- > > On Thu, Jun 9, 2016 at 4:25 AM, Larry Hastings wrote: > > THE PROBLEM > > ... > > The issue author had already identified the cause: CPython was

Re: [Python-Dev] BDFL ruling request: should we block forever waiting for high-quality random bits?

On Thu, Jun 09, 2016 at 08:26:20AM -0400, Donald Stufft wrote: > random.py > - > > In the abstract it doesn't hurt to seed MT with a CSPRNG, it just doesn't > provide much (if any) benefit and in this case it is hurting us because of the > cost on import (which will exist on other

Re: [Python-Dev] BDFL ruling request: should we block forever waiting for high-quality random bits?

On Thu, Jun 09, 2016 at 06:21:32PM +0100, Paul Moore wrote: > If we put the specific issue of applications that run very early in > system startup to one side, is there a possibility of running out of > entropy during normal system use? Even for a tiny duration? With /dev/urandom, I believe the

Re: [Python-Dev] Adding NewType() to PEP 484

On Fri, May 27, 2016 at 04:01:11PM -0700, Guido van Rossum wrote: > Also -- the most important thing. :-) What to call these things? We're > pretty much settled on the semantics and how to create them (A = > NewType('A', int)) but what should we call types like A when we're > talking about them?

Re: [Python-Dev] Adding NewType() to PEP 484

On Fri, May 27, 2016 at 09:26:29PM -0700, Guido van Rossum wrote: > We discussed this over dinner at PyCon, some ideas we came up with: > > - Dependent types, harking back to a similar concept in Ada > (https://en.wikibooks.org/wiki/Ada_Programming/Type_System#Derived_types) > which in that

Re: [Python-Dev] BDFL ruling request: should we block forever waiting for high-quality random bits?

On Sat, Jun 11, 2016 at 02:16:21PM -0700, Guido van Rossum wrote: [on the real-world consequences of degraded randomness from /dev/urandom] > Actually it's not clear to me at all that it could have happened to Python. > (Wasn't it an embedded system?) A Raspberry Pi. But don't people run Python

Re: [Python-Dev] [Python-checkins] cpython (3.5): Fix os.urandom() using getrandom() on Linux

Is this right? I thought we had decided that os.urandom should *not* fall back on getrandom on Linux? On Tue, Jun 14, 2016 at 02:36:27PM +, victor. stinner wrote: > https://hg.python.org/cpython/rev/e028e86a5b73 > changeset: 102033:e028e86a5b73 > branch: 3.5 > parent:

Re: [Python-Dev] Why does base64 return bytes?

On Tue, Jun 14, 2016 at 05:29:12PM +0100, Mark Lawrence via Python-Dev wrote: > As I've the time to play detective I'd suggest > https://mail.python.org/pipermail/python-3000/2007-July/008975.html Thanks Mark, that's great! -- Steve ___ Python-Dev

Re: [Python-Dev] Why does base64 return bytes?

On Tue, Jun 14, 2016 at 09:40:51PM -0700, Guido van Rossum wrote: > I'm officially on vacation, but I was surprised that people now assume > RFCs, which specify internet protocols, would have a bearing on programming > languages. (With perhaps an exception for RFCs that specifically specify > how

Re: [Python-Dev] Why does base64 return bytes?

On Wed, Jun 15, 2016 at 12:53:15PM +, Daniel Holth wrote: > In that case could we just add a base64_text() method somewhere? Who would > like to measure whether it would be a win? Just call .decode('ascii') on the output of base64.b64encode. Not every one-liner needs to be a standard

Re: [Python-Dev] Python parser performance optimizations

On Thu, May 26, 2016 at 10:19:05AM +, Artyom Skrobov wrote: [...] > The motivation for this patch was to enable a memory footprint > optimization, discussed at http://bugs.python.org/issue26415 My > proposed optimization reduces the memory footprint by up to 30% on the > standard

Re: [Python-Dev] JUMP_ABSOLUTE in nested if statements

On Sat, Jun 18, 2016 at 11:32:52PM +0100, Obiesie ike-nwosu via Python-Dev wrote: > That is much clearer now. > Thanks a lot Raymond for taking the time out to explain this to me. > On a closing note, is this mailing list the right place to ask these kinds > of n00b questions? That depends

Re: [Python-Dev] When to use EOFError?

On Mon, Jun 27, 2016 at 03:47:31PM -0700, Ethan Furman wrote: > On 06/27/2016 03:20 PM, Guido van Rossum wrote: > > >The point is that it's not an error. In Andre Malo's use case, at > >least, EOFError is used as a control flow exception, not as an error. > > Like StopIteration then: only an

Re: [Python-Dev] PEP 515: Underscores in Numeric Literals

On Wed, Feb 10, 2016 at 03:45:48PM -0800, Andrew Barnert via Python-Dev wrote: > On Feb 10, 2016, at 14:20, Georg Brandl wrote: > > First, general questions: should the PEP mention the Decimal constructor? > What about int and float (I'd assume int(s) continues to work as

Re: [Python-Dev] More optimisation ideas

On Thu, Feb 04, 2016 at 07:58:30PM -0500, Terry Reedy wrote: > >>For folks that *do* know how to use the terminal: > >> > >>$ python3 -m inspect --details inspect > >>Target: inspect > >>Origin: /usr/lib64/python3.4/inspect.py > >>Cached: /usr/lib64/python3.4/__pycache__/inspect.cpython-34.pyc >

Re: [Python-Dev] Time for a change of random number generator?

On Thu, Feb 11, 2016 at 01:08:41PM +1300, Greg Ewing wrote: > The Mersenne Twister is no longer regarded as quite state-of-the art > because it can get into states that produce long sequences that are > not very random. > > There is a variation on MT called WELL that has better properties > in

Re: [Python-Dev] Windows: Remove support of bytes filenames in theos module?

On Wed, Feb 10, 2016 at 12:41:08PM +1100, Chris Angelico wrote: > On Wed, Feb 10, 2016 at 12:37 PM, Steve Dower wrote: > > I really don't like the idea of not being able to use bytes in cross > > platform code. Unless it's become feasible to use Unicode for lossless > >

Re: [Python-Dev] PEP 515: Underscores in Numeric Literals

On Wed, Feb 10, 2016 at 08:41:27PM -0800, Andrew Barnert wrote: > And honestly, are you really claiming that in your opinion, "123_456_" > is worse than all of their other examples, like "1_23__4"? Yes I am, because 123_456_ looks like you've forgotten to finish typing the last group of

Re: [Python-Dev] PEP 515: Underscores in Numeric Literals

On Thu, Feb 11, 2016 at 08:07:56PM +1000, Nick Coghlan wrote: > Given that str.format supports a thousands separator: > > >>> "{:,d}".format(1) > '100,000,000' > > it might be reasonable to permit "_" in place of "," in the format specifier. +1 > However, I'm not sure when you'd use

Re: [Python-Dev] PEP 515: Underscores in Numeric Literals

On Thu, Feb 11, 2016 at 06:03:34PM +, Brett Cannon wrote: > On Thu, 11 Feb 2016 at 02:13 Steven D'Aprano <st...@pearwood.info> wrote: > > > On Wed, Feb 10, 2016 at 08:41:27PM -0800, Andrew Barnert wrote: > > > > > And honestly, are you really claimin

Re: [Python-Dev] PEP 515: Underscores in Numeric Literals

On Thu, Feb 11, 2016 at 08:50:09PM +0200, Serhiy Storchaka wrote: > I have strong preference for more strict and simpler rule, used by most > other languages -- "only between two digits". Main arguments: > > 1. Simple rule is easier to understand, remember and recognize. I care > not about the

Re: [Python-Dev] Issue #26204: compiler now emits a SyntaxWarning on constant statement

On Mon, Feb 08, 2016 at 05:43:25PM -0500, Yury Selivanov wrote: > > > On 2016-02-08 5:19 PM, Terry Reedy wrote: > >On 2/8/2016 4:51 PM, Victor Stinner wrote: > >>2016-02-08 22:28 GMT+01:00 Alexander Walters : > >>>What incantation do you need to do to make that behavior

Re: [Python-Dev] PEP 515: Underscores in Numeric Literals (revision 3)

On Sat, Feb 13, 2016 at 09:48:49AM +0100, Georg Brandl wrote: > Hi all, > > after talking to Guido and Serhiy we present the next revision > of this PEP. It is a compromise that we are all happy with, > and a relatively restricted rule that makes additions to PEP 8 > basically unnecessary. > >

<    4   5   6   7   8   9   10   11   12   13   >