Re: [Python-Dev] PEP 471 -- os.scandir() function -- a better and faster directory iterator

Hello, On Thu, 26 Jun 2014 18:59:45 -0400 Ben Hoyt wrote: > Hi Python dev folks, > > I've written a PEP proposing a specific os.scandir() API for a > directory iterator that returns the stat-like info from the OS, the > main advantage of which is to speed up os.walk() and similar > operations b

Re: [Python-Dev] PEP 471 -- os.scandir() function -- a better and faster directory iterator

Hello, On Thu, 26 Jun 2014 17:35:21 -0700 Benjamin Peterson wrote: > On Thu, Jun 26, 2014, at 17:07, Paul Sokolovsky wrote: > > > > With my MicroPython hat on, os.scandir() would make things only > > worse. With current interface, one can either have inefficient >

Re: [Python-Dev] PEP 471 -- os.scandir() function -- a better and faster directory iterator

Hello, On Thu, 26 Jun 2014 21:52:43 -0400 Ben Hoyt wrote: [] > It's a fair point that os.walk() can be implemented efficiently > without adding a new function and API. However, often you'll want more > info, like the file size, which scandir() can give you via > DirEntry.lstat(), which is free

Re: [Python-Dev] PEP 471 -- os.scandir() function -- a better and faster directory iterator

Hello, On Fri, 27 Jun 2014 12:08:41 +1000 Steven D'Aprano wrote: > On Fri, Jun 27, 2014 at 03:07:46AM +0300, Paul Sokolovsky wrote: > > > With my MicroPython hat on, os.scandir() would make things only > > worse. With current interface, one can either have inefficient &

Re: [Python-Dev] Fix Unicode-disabled build of Python 2.7

Hello, On Thu, 26 Jun 2014 22:49:40 +1000 Chris Angelico wrote: > On Thu, Jun 26, 2014 at 9:04 PM, Antoine Pitrou > wrote: > > For the same reason, I agree with Victor that we should ditch the > > threading-disabled builds. It's too much of a hassle for no actual, > > practical benefit. People

[Python-Dev] How io.IOBase.readline() should behave when used on non-blocking obj and no data available?

Hello, io.RawIOBase.read() is well specified for behavior in case it immediately gets a would-block condition: "If the object is in non-blocking mode and no bytes are available, None is returned." (https://docs.python.org/3/library/io.html#io.RawIOBase.read). However, nothing is said about such c

Re: [Python-Dev] How io.IOBase.readline() should behave when used on non-blocking obj and no data available?

Hello, On Thu, 16 Oct 2014 13:34:06 +0200 Antoine Pitrou wrote: > On Thu, 16 Oct 2014 03:54:32 +0300 > Paul Sokolovsky wrote: > > Hello, > > > > io.RawIOBase.read() is well specified for behavior in case it > > immediately gets a would-block condition: "I

Re: [Python-Dev] How io.IOBase.readline() should behave when used on non-blocking obj and no data available?

Hello, On Thu, 16 Oct 2014 07:50:02 -0700 Guido van Rossum wrote: [] > > > So, how readline() should behave in this case, and can that be > > > specified in the Library Reference? > > > > Well, the problem is that it's not obvious how to implement such > > methods in a non-blocking context. > >

[Python-Dev] Python 3.4.2 MSI fails to install and run on Windows For Devices

Hello, Following recent discussion of keeping Windows matters to the main dev list, I hope this message will be found useful. Please note that this is not a bug report, mostly a FYI. So, I tried to install Python 3.4.2 on an Intel Galileo board shipped with Windows For Devices. Actually, I don't

[Python-Dev] MicroPython 1.3.7 released

Hello, MicroPython is a Python3 language implementation which scales down to run on microcontrollers with tens of Ks of RAM and few hundreds of Ks of code size. Besides microcontrollers, it's also useful for small embedded Linux systems, where storage space is limited, for embedding as a scripting

Re: [Python-Dev] bytes & bytearray

Hello, On Mon, 19 Jan 2015 08:36:55 -0800 Ethan Furman wrote: > I was checking the documentation [1] to see where to put the new > information about bytes and bytearray %-formatting, and noticed > that /every/ operation that could modify a bytearray object in place > (e.g. center, capitalize, st

Re: [Python-Dev] bytes & bytearray

Hello, On Mon, 19 Jan 2015 14:03:20 -0800 Guido van Rossum wrote: > On Mon, Jan 19, 2015 at 11:43 AM, Paul Sokolovsky > wrote: > > > [...] > > So, suppose there's a requirement to support inplace operations > > (methods) on bytearray, what would

Re: [Python-Dev] bytes & bytearray

Hello, On Tue, 20 Jan 2015 18:15:02 +1300 Greg Ewing wrote: > Guido van Rossum wrote: > > On Mon, Jan 19, 2015 at 11:43 AM, Paul Sokolovsky > > mailto:pmis...@gmail.com>> wrote: > > > > b.lower_inplace() > > b.lower_i() > > > >

[Python-Dev] Builtin functions are magically static methods?

Hello, I looked into porting Python3 codecs module to MicroPython and saw rather strange behavior, which is best illustrated with following testcase: == def foo(a): print("func:", a) import _codecs fun = _codecs.utf_8_encode #fun = hash #fun = str.upper #fun = foo class Bar: me

Re: [Python-Dev] Keyword-only parameters

Hello, On Tue, 14 Apr 2015 13:40:40 -0400 "Eric V. Smith" wrote: > I'm working on adding a numeric_owner parameter to some tarfile > methods (http://bugs.python.org/issue23193), > > In a review, Berker suggested making the parameter keyword-only. I > agree that you'd likely never want to pass j

Re: [Python-Dev] Keyword-only parameters

Hello, On Tue, 14 Apr 2015 15:40:32 -0400 Larry Hastings wrote: > On 04/14/2015 01:56 PM, Paul Sokolovsky wrote: > > But newer parts of stdlib, e.g. asyncio, visibly overuse kw-only > > args. > > Overuse? asyncio? You mean "that thing Guido just wrote last &

Re: [Python-Dev] async/await PEP

Hello, On Fri, 17 Apr 2015 15:12:50 -0400 Yury Selivanov wrote: > Hello, > > I've just posted a new PEP about adding async/await to python-ideas. > Maybe I should have posted it here instead.. For reference, python-ideas archive link is https://mail.python.org/pipermail/python-ideas/2015-April

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

Hello, On Tue, 21 Apr 2015 11:56:15 +0100 Rob Cliffe wrote: > On 21/04/2015 10:33, Cory Benfield wrote: > > On 21 April 2015 at 10:10, Chris Angelico wrote: > >> At this point, you may want to just stop caring about the exact > >> type. Part of the point of gradual typing is that you can > >> s

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

Hello, On Tue, 21 Apr 2015 15:08:27 +0200 Antoine Pitrou wrote: [] > Because the user might not run the type checker, obviously. To quote > you: """When we say that type checking is optional, we mean it.""" > > You can't at the same time point out that type checking has no > power or control o

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

Hello, On Tue, 21 Apr 2015 16:11:51 +0200 Antoine Pitrou wrote: [] > >> You can't at the same time point out that type checking has no > >> power or control over runtime behaviour, and then claim that type > >> checking makes runtime behaviour (for example, ability to accept or > >> reject certa

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

Hello, On Tue, 21 Apr 2015 08:05:59 -0700 Nikolaus Rath wrote: > On Apr 20 2015, Chris Angelico wrote: > > Maybe it'd be of value to have a quick "code stripper" that takes > > away all the annotations, plus any other junk/framing that you're > > not interested in, and gives you something you c

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

Hello, On Tue, 21 Apr 2015 09:50:59 -0700 Ethan Furman wrote: > On 04/21, Paul Sokolovsky wrote: > > > > And for example yesterday's big theme was people blackmailing that > > they stop contributing to stdlib if annotations are in [...] > > A volunteer's

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

Hello, On Tue, 21 Apr 2015 12:17:01 -0400 "R. David Murray" wrote: > On Tue, 21 Apr 2015 18:27:50 +0300, Paul Sokolovsky > wrote: > > > I was replying to Steven's message. Did you read it? > > > > Yes. And I try to follow general course of discussion

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

Hello, On Wed, 22 Apr 2015 13:31:18 -0700 Guido van Rossum wrote: > On Wed, Apr 22, 2015 at 1:10 PM, Andrew Svetlov > wrote: > > > On Wed, Apr 22, 2015 at 10:44 PM, PJ Eby > > wrote: > > > On Tue, Apr 21, 2015 at 1:26 PM, Yury Selivanov > > > > > wrote: > > >> It is an error to pass a regula

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

Hello, On Wed, 22 Apr 2015 09:53:39 -0700 Rajiv Kumar wrote: > I'd like to suggest another way around some of the issues here, with > apologies if this has already been discussed sometime in the past. > > From the viewpoint of a Python programmer, there are two distinct > reasons for wanting to

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

Hello, On Thu, 23 Apr 2015 10:43:52 +0200 Wolfgang Langner wrote: [] > Also ask why no one used type specifier, they are possible since > Python 3.0 ? > Because it is the wrong way for Python. That's an example of how perceptions differ. In my list, everyone(*) uses them - MyPy, MicroPython, e

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

Hello, On Thu, 23 Apr 2015 20:39:51 +1200 Greg Ewing wrote: > Paul Sokolovsky wrote: > > And having both asymmetric and symmetric > > would quite confusing, especially that symmetric are more powerful > > and asymmetric can be easily implemented in terms of symmetric u

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

Hello, On Thu, 23 Apr 2015 12:18:51 +0300 Andrew Svetlov wrote: [] > > 3. > > async with and async for > > Bead idea, we clutter the language even more and it is one more > > thing every newbie could do wrong. > > for x in y: > > result = await f() > > is enough, every 'async' framework lived

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

Hello, On Thu, 23 Apr 2015 14:48:58 +0200 Wolfgang Langner wrote: > Hello, > > On Thu, Apr 23, 2015 at 11:59 AM, Paul Sokolovsky > wrote: > > > Hello, > > > > On Thu, 23 Apr 2015 10:43:52 +0200 > > Wolfgang Langner wrote: > > > > [] >

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

Hello, On Thu, 23 Apr 2015 09:15:44 -0400 Daniel Holth wrote: [] > >> Also ask why no one used type specifier, they are possible since > >> Python 3.0 ? > >> Because it is the wrong way for Python. > > > > That's an example of how perceptions differ. In my list, everyone(*) > > uses them - MyPy

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

Hello, On Thu, 23 Apr 2015 15:25:30 +0100 Harry Percival wrote: > lol @ the fact that the type hints are breaking github's syntax > highlighter :) What one can expect from software written in Ruby? ;-) -- Best regards, Paul mailto:pmis...@gmail.com _

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

Hello, On Fri, 24 Apr 2015 18:27:29 +0100 Ronan Lamy wrote: > Also ask why no one used type specifier, they are possible since > Python 3.0 ? > Because it is the wrong way for Python. > >>> > >>> That's an example of how perceptions differ. In my list, > >>> everyone(*) uses them

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

Hello, On Fri, 24 Apr 2015 12:04:27 -0700 Łukasz Langa wrote: [] > > > > They would likely search for something like > > r"^\s*def\s+[a-zA-Z0-9_]+" which will hit "def async spam" but not > > "async def”. > > Realistically that can’t be what they’re doing because of multiple > string literals,

Re: [Python-Dev] PEP 492: No new syntax is required

Hello, On Sun, 26 Apr 2015 16:40:03 -0400 Yury Selivanov wrote: > Hi Mark, > > On 2015-04-26 4:21 PM, Mark Shannon wrote: > > Hi, > > > > I was looking at PEP 492 and it seems to me that no new syntax is > > required. > > Mark, all your points are explained in the PEP in a great detail: Inde

Re: [Python-Dev] PEP 492: No new syntax is required

Hello, On Sun, 26 Apr 2015 18:49:43 -0400 Yury Selivanov wrote: [] > >> >- it would look confusing > > Sorry, "async def __enter__" doesn't look more confusing than > > "__aenter__" (vs "__enter__"). > > I'll update the PEP. > > The argument shouldn't be that it's confusing, the argument > is

Re: [Python-Dev] PEP 492: No new syntax is required

Hello, On Sun, 26 Apr 2015 16:13:43 -0700 Guido van Rossum wrote: > But new syntax is the whole point of the PEP. I want to be able to > *syntactically* tell where the suspension points are in coroutines. > Currently this means looking for yield [from]; PEP 492 just adds > looking for await and

Re: [Python-Dev] PEP 492: No new syntax is required

Hello, On Sun, 26 Apr 2015 19:45:30 -0400 Yury Selivanov wrote: [] > > Then, is the only logic for proposing __aenter__ is to reinsure > > against a situation that someone starts to write async context > > manager, forgets that they write async context manager, and make an > > __enter__ method

Re: [Python-Dev] PEP 492: No new syntax is required

Hello, On Sun, 26 Apr 2015 20:39:55 -0400 Yury Selivanov wrote: [] > > As for 3rd point, I'd like to remind that CPython is only one Python > > implementation. And with my MicroPython hat on, I'd like to know if > > (some of) these new features are "bloat" or "worthy" for the space > > constrai

Re: [Python-Dev] PEP 492: No new syntax is required

Hello, On Mon, 27 Apr 2015 08:48:49 +0100 Mark Shannon wrote: > > > On 27/04/15 00:13, Guido van Rossum wrote: > > But new syntax is the whole point of the PEP. I want to be able to > > *syntactically* tell where the suspension points are in coroutines. > Doesn't "yield from" already do that?

Re: [Python-Dev] Issues with PEP 482 (1)

Hello, On Tue, 28 Apr 2015 19:44:53 +0100 Mark Shannon wrote: [] > A coroutine without a yield statement can be defined simply and > concisely, thus: > > @coroutine > def f(): > return 1 [] > A pure-python definition of the "coroutine" decorator is > given below. > [] > from types i

Re: [Python-Dev] PEP 492: No new syntax is required

Hello, On Tue, 28 Apr 2015 20:59:18 +0100 Mark Shannon wrote: > > > On 28/04/15 20:24, Paul Sokolovsky wrote: > > Hello, > > > [snip] > > > Based on all this passage, my guess is that you miss difference > > between C and Python functions. > This is

Re: [Python-Dev] Issues with PEP 482 (1)

Hello, On Tue, 28 Apr 2015 21:00:17 +0100 Mark Shannon wrote: [] > >> CO_COROUTINE = 0x0080 > >> CO_GENERATOR = 0x0020 > >> > >> def coroutine(f): > >> 'Converts a function to a generator function' > >> old_code = f.__code__ > >> new_code = CodeType( > >> old_code.co

Re: [Python-Dev] PEP 492: What is the real goal?

Hello, On Wed, 29 Apr 2015 20:19:40 +0100 Paul Moore wrote: [] > Thanks for that. That does look pretty OK. One question, though - it > uses an asyncio Queue. The original code would work just as well with > a list, or more accurately, something that wasn't designed for async > use. So the tran

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

Hello, On Wed, 29 Apr 2015 20:33:09 -0400 Yury Selivanov wrote: > Hi Ethan, > > On 2015-04-29 8:21 PM, Ethan Furman wrote: > > From the PEP: > > > >> Why not a __future__ import > >> > >> __future__ imports are inconvenient and easy to forget to add. > > That is a horrible rationale for not us

Re: [Python-Dev] PEP 492: What is the real goal?

Hello, On Thu, 30 Apr 2015 18:53:00 +1200 Greg Ewing wrote: > Skip Montanaro wrote: > > According to Wikipedia , > > term "coroutine" was first coined in 1958, so several generations > > of computer science graduates will be familiar with the textbook > >

Re: [Python-Dev] Minimal async event loop and async utilities (Was: PEP 492: async/await in Python; version 4)

Hello, On Wed, 6 May 2015 09:27:16 +0100 Paul Moore wrote: > On 6 May 2015 at 07:46, Greg Ewing > wrote: > > Another problem with the "core" idea is that > > you can't start with an event loop that "just does > > scheduling" and then add on other features such > > as I/O *from the outside*. The

Re: [Python-Dev] Guarantee ordered dict literals in v3.7?

Hello, On Sun, 5 Nov 2017 12:04:41 +1000 Nick Coghlan wrote: > On 5 November 2017 at 04:35, Guido van Rossum > wrote: > > This sounds reasonable -- I think when we introduced this in 3.6 we > > were worried that other implementations (e.g. Jython) would have a > > problem with this, but AFAIK t

Re: [Python-Dev] Guarantee ordered dict literals in v3.7?

Hello, On Mon, 6 Nov 2017 11:36:59 +0100 Stefan Krah wrote: > On Mon, Nov 06, 2017 at 12:18:17PM +0200, Paul Sokolovsky wrote: > > MicroPython hashmap implementation is effectively O(n) (average and > > worst case) due to the algorithm parameters chosen (like the load >

Re: [Python-Dev] Guarantee ordered dict literals in v3.7?

Hello, On Mon, 6 Nov 2017 14:30:45 +0100 Antoine Pitrou wrote: > On Tue, 7 Nov 2017 00:14:35 +1100 > Steven D'Aprano wrote: > > On Mon, Nov 06, 2017 at 12:27:54PM +0100, Antoine Pitrou wrote: > > > > > The ordered-ness of dicts could instead become one of those stable > > > CPython implement

Re: [Python-Dev] Guarantee ordered dict literals in v3.7?

Hello, On Mon, 06 Nov 2017 17:58:47 + Brett Cannon wrote: [] > > Why suddenly once in 25 years there's a need to do something to > > dict's, violating computer science background behind them (one of > > the reason enough people loved Python comparing to other "practical > > hack" languages)

Re: [Python-Dev] Guarantee ordered dict literals in v3.7?

Hello, On Mon, 6 Nov 2017 11:33:10 -0800 Barry Warsaw wrote: [] > If we did make the change, it’s possible we would need a way to > explicit say that order is not preserved. That seems a little weird I recently was working on a more or less complex dataflow propagation problem. It should conv

Re: [Python-Dev] Guarantee ordered dict literals in v3.7?

Hello, On Tue, 7 Nov 2017 17:33:03 +1100 Steven D'Aprano wrote: > On Mon, Nov 06, 2017 at 06:35:48PM +0200, Paul Sokolovsky wrote: > > > For MicroPython, it would lead to quite an overhead to make > > dictionary items be in insertion order. As I mentioned, MicroPython

Re: [Python-Dev] Guarantee ordered dict literals in v3.7?

Hello, On Tue, 7 Nov 2017 14:40:07 +0900 INADA Naoki wrote: > I agree with Raymond. dict ordered by default makes better developer > experience. > > So, my concern is how "language spec" is important for minor (sorry > about my bad vocabulary) implementation? > What's difference between "Micro

Re: [Python-Dev] Using async/await in place of yield expression

Hello, On Mon, 27 Nov 2017 15:33:51 +1000 Caleb Hattingh wrote: [] > The PEP only says that __await__ must return an iterator, but it > turns out that it's also required that that iterator > should not return any intermediate values. This requirement is only > enforced in the event loop, not >

Re: [Python-Dev] Deprecate PEP 370 Per user site-packages directory?

Hello, On Sat, 13 Jan 2018 19:18:41 +0100 Christian Heimes wrote: [] > >> Nowadays Python has venv in the standard library. The user-specific > >> site-packages directory is no longer that useful. I would even say > >> it's causing more trouble than it's worth. For example it's common > >> for

Re: [Python-Dev] Keeping competitive with Go (was Re: Computed Goto dispatch for Python 2)

Hello, On Thu, 28 May 2015 23:48:59 +0200 Matthias Klose wrote: [] > And the very same place where you are working is investing in getting > shared libraries working for Go. Single binaries may be popular for > distributing end user applications, but definitely not for > distributing a core OS

Re: [Python-Dev] Computed Goto dispatch for Python 2

Hello, On Fri, 29 May 2015 08:38:44 +1000 Nick Coghlan wrote: [] > In that vein, it might be interesting to see what could be done with > MicroPython in terms of providing a lightweight portable Python > runtime without CPython's extensive integration with the underlying > OS. Thanks for menti

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

Hello, On Fri, 29 May 2015 20:53:53 +1000 Steven D'Aprano wrote: [ insightful statistics skipped ] > I think there are some exciting and interesting languages coming up: > Swift, Julia, Go, Rust and others. Only those? Every one in a dozen university student comes up with an exciting, intere

Re: [Python-Dev] Single-file Python executables (including case of self-sufficient package manager)

Hello, On Fri, 29 May 2015 08:35:44 -0400 Donald Stufft wrote: [] > Another example is one that I personally worked on recently, where > the company I worked for wanted to distribute a CLI to our customers > which would "just work" that they could use to interact with the [] > particular piece

Re: [Python-Dev] 2.7 is here until 2020, please don't call it a waste.

Hello, On Mon, 01 Jun 2015 13:14:27 +0200 "M.-A. Lemburg" wrote: [] > > The "7.0x faster" number on speed.pypy.org would be significantly > > *higher* if we upgraded the baseline to 2.7.10 now. > > If someone were to volunteer to set up and run speed.python.org, > I think we could add some add

Re: [Python-Dev] Importance of "async" keyword

Hello, On Sat, 27 Jun 2015 00:31:01 +1000 Chris Angelico wrote: > On Sat, Jun 27, 2015 at 12:20 AM, Ethan Furman > wrote: > > As Nick said earlier: the caller always blocks; by extension (to my > > mind, at least) putting an `await` in front of something is saying, > > "it's okay if other tasks

[Python-Dev] [ANN] MicroPython 1.5

Hello, MicroPython is a lean and efficient Python implementation for microcontrollers, embedded, and mobile systems (which also runs just as fine on desktops of course). https://github.com/micropython/micropython Recent 1.5 release is an important milestone for the project, major changes includi

Re: [Python-Dev] async/await behavior on multiple calls

Hello, On Tue, 15 Dec 2015 17:29:26 -0800 Roy Williams wrote: > @Kevin correct, that's the point I'd like to discuss. Most other > mainstream languages that implements async/await expose the > programming model with Tasks/Futures/Promises as opposed to > coroutines PEP 492 states 'Objects with

Re: [Python-Dev] Fun with ancient unsupported platforms

Hello, On Thu, 28 Jan 2016 17:29:41 +0100 Victor Stinner wrote: > We slowly remove old platforms, but only if the code specific to these > old platforms is annoying to maintain. For example, I wrote the > change: > > https://hg.python.org/cpython/rev/a1605d2508af > """ > Issue #22591: Drop supp

[Python-Dev] [ANN] MicroPython 1.6

Hello, MicroPython is a lean and efficient Python implementation for microcontrollers, embedded, and mobile systems (which also runs just as fine on desktops, servers, and clouds). https://github.com/micropython/micropython https://github.com/micropython/micropython/releases/tag/v1.6 There're fo

Re: [Python-Dev] Very old git mirror under github user "python-git"

Hello, On Sun, 28 Feb 2016 18:46:36 +0100 Georg Brandl wrote: [] > > 3) If still nothing can be done make a DMCA request. You can likely > > argue that the logo/name are used without PSF content. > > https://help.github.com/articles/dmca-takedown-policy/ > > Please no. There is absolutely n

[Python-Dev] Clarification on MRO when inheriting from builtin type.

Hello, I used http://python-history.blogspot.com/2010/06/method-resolution-order.html and https://www.python.org/download/releases/2.3/mro/ as the reference, but it doesn't explain MRO in the following example (python3.4): class User: def __str__(self): return "User.__str__"

Re: [Python-Dev] Clarification on MRO when inheriting from builtin type.

Hello, On Mon, 28 Apr 2014 13:13:53 +1000 Chris Angelico wrote: > On Mon, Apr 28, 2014 at 12:59 PM, Paul Sokolovsky > wrote: > > From the output, "User" class as expected does not override > > list.append(), but does override list.__str__(). Is this behavior > &

[Python-Dev] Multiple inheritance from builtin (C) types [still] supported in Python3?

Hello, It's more or less known fact (ref: google) that you can't inherit from multiple generic builtin (as in "coded in C") types: class C(dict, list): pass TypeError: multiple bases have instance lay-out conflict However, more detailed googling led me to this page of a book: http://books.googl

Re: [Python-Dev] Multiple inheritance from builtin (C) types [still] supported in Python3?

Hello, On Mon, 28 Apr 2014 20:24:58 +0200 Antoine Pitrou wrote: > On Mon, 28 Apr 2014 20:45:48 +0300 > Paul Sokolovsky wrote: > > > > So, is that it, or disjoint native types are supported as bases > > somehow? Also, would someone know if a class-subclass case ha

Re: [Python-Dev] Multiple inheritance from builtin (C) types [still] supported in Python3?

Hello, On Mon, 28 Apr 2014 12:08:40 -0700 Guido van Rossum wrote: [] > > How is "compatible layout" defined? Or "layout" for that matter at > > all? > > > > The layout is what the C struct defining the object looks like. These > are typically defined in headers in the Include directory (e.g. >

Re: [Python-Dev] Multiple inheritance from builtin (C) types [still] supported in Python3?

Hello, On Tue, 29 Apr 2014 10:47:26 -0400 PJ Eby wrote: [] > > From memory of the last time I dealt with this, the rules were that > you could mix two classes only if their __slots__ differed from their > common __base__ by *at most* __dict__ and/or __weakref__. The dict > and weakref slots ar

Re: [Python-Dev] Internal representation of strings and Micropython

Hello, On Wed, 4 Jun 2014 17:03:22 +1000 Chris Angelico wrote: [] > > Why not support variable-width strings like CPython 3.4? > > That was my first recommendation, and in fact I started writing code > to implement parts of PEP 393, with a view to basically doing it the > same way in both Pyth

Re: [Python-Dev] Internal representation of strings and Micropython

Hello, On Wed, 4 Jun 2014 12:32:12 +1000 Chris Angelico wrote: > On Wed, Jun 4, 2014 at 11:17 AM, Steven D'Aprano > wrote: > > * Having a build-time option to restrict all strings to ASCII-only. > > > > (I think what they mean by that is that strings will be like > > Python 2 strings, ASCII-p

Re: [Python-Dev] Internal representation of strings and Micropython

Hello, On Tue, 3 Jun 2014 22:23:07 -0700 Guido van Rossum wrote: [] > Never mind disabling assertions -- even with enabled assertions you'd > have to expect most Python programs to fail with non-ASCII input. > > Then again the UTF-8 option would be pretty devastating too for > anything manipula

Re: [Python-Dev] Internal representation of strings and Micropython

Hello, On Wed, 4 Jun 2014 20:53:46 +1000 Chris Angelico wrote: > On Wed, Jun 4, 2014 at 8:38 PM, Paul Sokolovsky > wrote: > > And I'm saying that not to discourage Unicode addition to > > MicroPython, but to hint that "force-force" approach implemented by

Re: [Python-Dev] Internal representation of strings and Micropython

Hello, On Wed, 4 Jun 2014 21:17:12 +1000 Chris Angelico wrote: > On Wed, Jun 4, 2014 at 9:12 PM, Paul Sokolovsky > wrote: > > An alternative view is that the discussion on the tracker showed > > Python developers' mind-fixation on implementing something the way >

Re: [Python-Dev] Internal representation of strings and Micropython

Hello, On Thu, 5 Jun 2014 00:26:10 +1000 Chris Angelico wrote: > On Thu, Jun 5, 2014 at 12:17 AM, Serhiy Storchaka > wrote: > > 04.06.14 10:03, Chris Angelico написав(ла): > > > >> Right, which is why I don't like the idea. But you don't need > >> non-ASCII characters to blink an LED or turn a

Re: [Python-Dev] Internal representation of strings and Micropython

Hello, On Wed, 04 Jun 2014 17:40:14 +0300 Serhiy Storchaka wrote: > 04.06.14 17:02, Paul Moore написав(ла): > > On 4 June 2014 14:39, Serhiy Storchaka wrote: > >> I think than breaking O(1) expectation for indexing makes the > >> implementation significant incompatible with Python. Virtually al

Re: [Python-Dev] Internal representation of strings and Micropython

Hello, On Thu, 5 Jun 2014 01:00:52 +1000 Chris Angelico wrote: > On Thu, Jun 5, 2014 at 12:49 AM, Paul Sokolovsky > wrote: > >> > But you need non-ASCII characters to display a title of MP3 > >> > track. > > > > Yes, but to display a title, you don&#

Re: [Python-Dev] Internal representation of strings and Micropython

Hello, On Wed, 04 Jun 2014 19:49:18 +0300 Serhiy Storchaka wrote: [] > > But show me real-world case for that. Common usecase is scanning > > string left-to-right, that should be done using iterator and thus > > O(N). Right-to-left scanning would be order(s) of magnitude less > > frequent, as an

Re: [Python-Dev] Internal representation of strings and Micropython

Hello, On Wed, 04 Jun 2014 20:52:14 +0300 Serhiy Storchaka wrote: [] > > That's sad, I agree. > > Other languages (Go, Rust) can be happy without O(1) indexing of > strings. All string and regex operations work with iterators or > cursors, and I believe this approach is not significant worse t

Re: [Python-Dev] Internal representation of strings and Micropython

Hello, On Wed, 4 Jun 2014 11:25:51 -0700 Guido van Rossum wrote: > This thread has devolved into a flame war. I think we should trust the > Micropython implementers (whoever they are -- are they participating > here?) I'm a regular contributor. I'm not sure if the author, Damien George, is on

Re: [Python-Dev] Internal representation of strings and Micropython

Hello, On Wed, 04 Jun 2014 18:04:52 -0400 Terry Reedy wrote: > On 6/4/2014 5:14 PM, Paul Sokolovsky wrote: > > > That said, and unlike previous attempts to develop a small Python > > implementations (which of course existed), we're striving to be > > exactly a P

Re: [Python-Dev] Internal representation of strings and Micropython

Hello, On Wed, 4 Jun 2014 16:12:23 -0600 Eric Snow wrote: > On Wed, Jun 4, 2014 at 3:14 PM, Paul Sokolovsky > wrote: > > That said, and unlike previous attempts to develop a small Python > > implementations (which of course existed), we're striving to be > &

Re: [Python-Dev] Internal representation of strings and Micropython

Hello, On Thu, 05 Jun 2014 12:03:17 +1200 Greg Ewing wrote: > Serhiy Storchaka wrote: > > html.HTMLParser, json.JSONDecoder, re.compile, tokenize.tokenize > > don't use iterators. They use indices, str.find and/or regular > > expressions. Common use case is quickly find substring starting > > fr

Re: [Python-Dev] Internal representation of strings and Micropython

Hello, On Thu, 05 Jun 2014 12:08:21 +1200 Greg Ewing wrote: > Serhiy Storchaka wrote: > > A language which doesn't support O(1) indexing is not Python, it is > > only Python-like language. > > That's debatable, but even if it's true, I don't think > there's anything wrong with MicroPython being

Re: [Python-Dev] Internal representation of strings and Micropython

Hello, On Wed, 04 Jun 2014 22:15:30 -0400 Terry Reedy wrote: > On 6/4/2014 6:52 PM, Paul Sokolovsky wrote: > > > "Well" is subjective (or should be defined formally based on the > > requirements). With my MicroPython hat on, an implementation which > > receive

Re: [Python-Dev] Internal representation of strings and Micropython

Hello, On Thu, 05 Jun 2014 16:54:11 +0900 "Stephen J. Turnbull" wrote: > Paul Sokolovsky writes: > > > Please put that in perspective when alarming over O(1) indexing of > > inherently problematic niche datatype. (Again, it's not my or > > MicroPython

Re: [Python-Dev] Internal representation of strings and Micropython

Hello, On Thu, 5 Jun 2014 21:43:16 +1000 Nick Coghlan wrote: > On 5 June 2014 21:25, Paul Sokolovsky wrote: > > Well, I understand the plan - hoping that people will "get over > > this". And I'm personally happy to stay away from this "trolling", > &

Re: [Python-Dev] Internal representation of strings and Micropython

Hello, On Thu, 5 Jun 2014 22:20:04 +1000 Nick Coghlan wrote: [] > problems caused by trusting the locale encoding to be correct, but the > startup code will need non-trivial changes for that to happen - the > C.UTF-8 locale may even become widespread before we get there). ... And until those go

Re: [Python-Dev] Internal representation of strings and Micropython

Hello, On Thu, 5 Jun 2014 22:21:30 +1000 Tim Delaney wrote: > On 5 June 2014 22:01, Paul Sokolovsky wrote: > > > > > All these changes are what let me dream on and speculate on > > possibility that Python4 could offer an encoding-neutral string type > &g

Re: [Python-Dev] Internal representation of strings and Micropython

Hello, On Thu, 5 Jun 2014 22:38:13 +1000 Nick Coghlan wrote: > On 5 June 2014 22:10, Stefan Krah wrote: > > Paul Sokolovsky wrote: > >> In this regard, I'm glad to participate in mind-resetting > >> discussion. So, let's reiterate - there's nothing li

Re: [Python-Dev] Internal representation of strings and Micropython

Hello, On Thu, 5 Jun 2014 23:15:54 +1000 Nick Coghlan wrote: > On 5 June 2014 22:37, Paul Sokolovsky wrote: > > On Thu, 5 Jun 2014 22:20:04 +1000 > > Nick Coghlan wrote: > >> problems caused by trusting the locale encoding to be correct, but > >> the startup c

Re: [Python-Dev] Internal representation of strings and Micropython

Hello, On Fri, 06 Jun 2014 20:11:27 +0900 "Stephen J. Turnbull" wrote: > Paul Sokolovsky writes: > > > That kinda means "string is atomic", instead of your "characters > > are atomic". > > I would be very surprised if a language tha

Re: [Python-Dev] Internal representation of strings and Micropython

Hello, On Fri, 06 Jun 2014 09:32:25 +0100 Mark Lawrence wrote: > On 04/06/2014 16:52, Mark Lawrence wrote: > > On 04/06/2014 16:32, Steve Dower wrote: > >> > >> If copying into a separate list is a problem (memory-wise), > >> re.finditer('\\S+', string) also provides the same behaviour and > >>

Re: [Python-Dev] Internal representation of strings and Micropython

Hello, On Fri, 6 Jun 2014 21:48:41 +1000 Tim Delaney wrote: > On 6 June 2014 21:34, Paul Sokolovsky wrote: > > > > > On Fri, 06 Jun 2014 20:11:27 +0900 > > "Stephen J. Turnbull" wrote: > > > > > Paul Sokolovsky writes: > > > >

Re: [Python-Dev] Internal representation of strings and Micropython

Hello, On Fri, 06 Jun 2014 11:59:31 -0400 Terry Reedy wrote: [] > The other problem is that a small slice view of a large object keeps > the large object alive, so a view user needs to think carefully about > whether to make a copy or create a view, and later to copy views to > delete the bas

Re: [Python-Dev] namedtuple implementation grumble

Hello, On Sat, 07 Jun 2014 12:42:32 -0700 Glenn Linderman wrote: > On 6/7/2014 7:50 AM, Antoine Pitrou wrote: > > Le 07/06/2014 09:25, R. David Murray a écrit : > >> On Fri, 06 Jun 2014 19:50:57 +0100, Chris Withers > >> wrote: > >>> I guess I could duck-type it based on the _fields attribute

Re: [Python-Dev] cpython and python debugger documentation

Hello, On Mon, 09 Jun 2014 14:01:18 + Brett Cannon wrote: > On Sat Jun 07 2014 at 5:55:29 PM, Le Pa wrote: > > > Hi, > > > > I am interested in learning how the cpython interpreter is designed > > and implemented, > > and also how the python debugger works internally. My ultimate > > purpo

  1   2   3   >