[Python-Dev] Re: Small lament...

[Eric Fahlgren]

Oh, man, it has been a while.  The last one I remember is PEP 404 (if you
can find it :) ), dated 2011 and it wasn't an April Fool's...

On Sat, Apr 1, 2023 at 11:23 AM Skip Montanaro 
wrote:

> Just wanted to throw this out there... I lament the loss of waking up on
> April 1st to see a creative April Fool's Day joke on one or both of these
> lists, often from our FLUFL... Maybe such frivolity still happens, just not in
> the Python ecosystem? I know you can still import "this" or
> "antigravity", but those are now old (both introduced before 2010). When
> was the last time a clever easter egg was introduced or an April Fool's Day
> joke played?
>
> ¯\_(ツ)_/¯
>
> Skip
>
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/Q62W2Q6R6XMX57WK2CUGEENHMT3C3REF/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/TIBOHJYFSHVSAIBZQPMEXHUH2KWPJMCC/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Expectations of typing (was: The current state of typing PEPs)

[Eric Fahlgren]

On Wed, Dec 1, 2021 at 10:50 PM Christopher Barker 
wrote:

> I know this isn't really the place for this conversation, but:
>
>
>> which is what `os.PathLike` represents, hence why `str` isn't covered by
>> it);
>>
>
> wait, what? It seems so clear to me that "PathLike" (as a type specifier)
> would mean: anything that can be passed into os.fspath to give me a path.
> (or, of course to the stdlib functions that take paths)
>
> Isn't the entire purpose of os.fspath that you can write code like:
>
> def fun(some_kind_of_path):
>some_kind_of_path = os.fspath(some_kind_of_path)
>
>(or just pass it to a function you takes PathLIke)
>
> and go on your merry way -- e.g. duck typing, baby!
>
> Is there really no way to annotate that simply now?
>

Assuming you want the return value of 'fun' to be covariant with the path
input, I believe you would say this:

def fun(some_kind_of_path: str) -> str: ...
def fun(some_kind_of_path: bytes) -> bytes: ...
def fun(some_kind_of_path: os.PathLike[AnyStr]) -> AnyStr:
some_kind_of_path = os.fspath(some_kind_of_path)
# transform it
return some_kind_of_path

I would love to be shown how to do this with just a one-line declaration of
'fun', but I've given up trying to figure it out.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/PI6TR73ZQRDMKDNBUH3AQOK4IYUERB7F/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 467: Minor bytes and bytearray improvements

[Eric Fahlgren]

On Thu, Nov 4, 2021 at 12:01 AM Ethan Furman  wrote:

>  >>> bytearray.fromsize(5, fill=b'\x0a')
>  bytearray(b'\x0a\x0a\x0a\x0a\x0a')
>

What happens if you supply more than one byte for the fill argument?
Silent truncation, raise ValueError('too long') or ???
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/GHXKHPNJSEK6SRNG2O3ZLZMKAEZTMVLS/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 622: Structural Pattern Matching [was: PEP 622 railroaded through?]

[Eric Fahlgren]

On Tue, 7 Jul 2020 at 15:04, Rob Cliffe via Python-Dev <
python-dev@python.org> wrote:

>  I don't like the .name syntax (grit on Tim's monitor; does not
>> suggest the meaning). [...] But I don't know what syntax (where
>> necessary) to suggest.
>
>
https://photos.app.goo.gl/xN68s3QMMBTPTLD47   Look about two character
spaces left of "I don't like..."

As I read this part of Rob's post this morning, I thought he was
surreptitiously making a point about grit on the screen, when I noticed it
was *literally grit on the screen*.  I cannot convey how long it took me to
recover.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/XRHUZGM7HP6S6Z7UQTYTIE7GO64S7LIP/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Accepting PEP 618: zip(strict=True)

[Eric Fahlgren]

On Thu, Jun 18, 2020 at 8:06 AM Serhiy Storchaka 
wrote:

> It would be easier if add a new function instead of a new keyword
> argument to the existing function.
>

We've implemented the new zip in our sitecustomize.py, and think the
keyword makes it easier.  I've instructed our development staff to examine
all use of zip as they come across them and add either "strict=True" or
"strict=False" when they've determined which is appropriate.  Any zip calls
without an explicit "strict=" will be deemed "unknown" and requiring
further investigation.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/EUREEQNPGPMIIZ4MUQJWUBLN2CZGF53Y/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP: Modify the C API to hide implementation details

[Eric Fahlgren]

On Mon, Apr 13, 2020 at 9:00 AM Steve Dower  wrote:

> On 13Apr2020 1325, Paul Moore wrote:
> > Personally, I'd say that "recommended 3rd party tools" reads as saying
> > "if you want a 3rd party tool to build extensions, these are good (and
> > are a lot easier than using the raw C API)". That's a lot different
> > than saying "we recommend that people writing C extensions do not use
> > the raw C API, but use one of these tools instead".
>
> Yeah, that's fair. But at the same time, saying anything more strong is
> an endorsement that we might have to withdraw at some point in the
> future (if the project we recommend implodes, for example).
>

Ok, so put that in a Pros/Cons list that provides guidance as to what
interface and tools to choose when writing a new extension module.
Personally, I'd put Cython (and other "big" packages, numpy, requests and
such) on par with CPython itself with respect to "likely to implode and
become unusable."
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/VFRGMKVVE3OUJUXARNEIC67GFC6H22K7/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 616 -- String methods to remove prefixes and suffixes

[Eric Fahlgren]

On Tue, Mar 24, 2020 at 2:53 PM Ethan Furman  wrote:

> On 03/24/2020 01:37 PM, Eric V. Smith wrote:
> > On 3/24/2020 3:30 PM, Steve Dower wrote:
> >> On 24Mar2020 1849, Brett Cannon wrote:
> >>> -1 on "cut*" because my brain keeps reading it as "cute".
> >>> +1 on "trim*" as it is clear what's going on and no confusion with
> preexisting methods.
> >>> +1 on "remove*" for the same reasons as "trim*".
> >>>
> >>> And if no consensus is reached in this thread for a name I would
> assume the SC is going to ultimately decide on the name if the PEP is
> accepted as the burden of being known as "the person who chose _those_
> method names on str" is more than any one person should have bear. ;)
> >>
> >> -1 on "cut*" (feels too much like what .partition() does)
> >> -0 on "trim*" (this is the name used in .NET instead of "strip", so I
> foresee new confusion)
> >> +1 on "remove*" (because this is exactly what it does)
>
I think name choice is easier if you write the documentation first:

cutprefix - Removes the specified prefix.
trimprefix - Removes the specified prefix.
stripprefix - Removes the specified prefix.
removeprefix - Removes the specified prefix.  Duh. :)
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/45YMVG53WMKN66JXZV7VO2LPFQ5W3Z4F/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 616 -- String methods to remove prefixes and suffixes

[Eric Fahlgren]

On Fri, Mar 20, 2020 at 11:56 AM Dennis Sweeney 
wrote:

> If ``s`` is one these objects, and ``s`` has ``pre`` as a prefix, then
> ``s.cutprefix(pre)`` returns a copy of ``s`` in which that prefix has
> been removed.  If ``s`` does not have ``pre`` as a prefix, an
> unchanged copy of ``s`` is returned.  In summary, ``s.cutprefix(pre)``
> is roughly equivalent to ``s[len(pre):] if s.startswith(pre) else s``.
>

The second sentence above unambiguously states that cutprefix returns 'an
unchanged *copy*', but the example contradicts that and shows that 'self'
may be returned and not a copy.  I think it should be reworded to
explicitly allow the optimization of returning self.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/SVDEUYYJSI6RRHEOZ54CD55FJRY5N4KM/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Should we require all deprecations to have a removal version that we follow through on?

[Eric Fahlgren]

On Thu, Nov 28, 2019 at 10:02 AM Brett Cannon  wrote:

> But there is other things that might break your code between releases,
> such as bug fixes, language changes that become the default, etc. Are
> deprecations the biggest pain point in transitioning to a new Python
> version for people, or is it just part of a greater culmination of changes?
>

I just started the 3.7 -> 3.8 migration on our codebase yesterday, so this
is fresh in my mind (about 500k LOC with 72 external packages plus four
home-built extension modules, three of which use SWIG wrapping).  My
biggest pain point is making the external extension modules work due to API
changes; deprecations are only a minor issue, although that's probably
because we turn all warnings on during development and clean things up as
soon as they appear (if there are any win32.pywintypes devs listening, fix
that use of the old imp module at line 2).

Things I fixed quickly include some int vs float warnings in our GUI code,
replacing the call to create a new CodeType object with a code.replace, and
repair some SyntaxWarnings where "is" had crept into places where "=="
should have been used.  So, all good improvements to the code and I've
spent far longer thus far on other aspects of the porting.

I would be on the side of "sooner is better", with three releases of
deprecated, we-really-mean-it and gone.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/MAPZHRVXLWLOOEP2US3P6UUNFN6JWPKS/
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-Dev] Finding Guido's replacement

[Eric Fahlgren]

On Sun, Jul 22, 2018 at 1:19 PM Chris Angelico  wrote:

> * Finally, "For Life" is far too long. We need to change our rulers
> periodically.
>

​With the proposed bi-weekly death matches, "for life" may actually be too
short.​
___
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] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)

[Eric Fahlgren]

On Wed, Jun 27, 2018 at 9:27 AM Paul Moore  wrote:

> From my reading, PEP 572 takes the position that "parent local
> scoping" is what people expect from assignment expressions *in
> comprehensions* and it's useful enough that there is no reason not to
> make that the behaviour. The behaviour isn't generally useful enough
> to be worth exposing as a primitive (it's not even useful enough for
> the PEP to give it an explicit name!) so it's just a special case for
> assignment expressions in comprehensions/generators.
>

​So, my interpretation is that it will behave like this?

x = 2
y = [x := 3 for i in range(1)]
print(x)
3

def f():
x = 4
y = [x := 5 for i in range(1)]
print(x)
f()
5

class C:
x = 6
y = [x := 7 for i in range(1)]
print(x)
C()
6
print(x)
7​
___
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] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)

[Eric Fahlgren]

On Mon, Jun 25, 2018 at 2:16 PM Steve Holden  wrote:

> ​I'd like to ask: how many readers of ​
>
> ​this email have ever deliberately taken advantage of the limited Python 3
> scope in comprehensions and generator expressions to use what would
> otherwise be a conflicting local variable name?​
>

​No, never, but the opposite has bitten me in production code (as I related
several months back, a class-level variable was being used on the lhs of a
comprehension and that failed when it was run in Py3).

The caveat is that our code base is Py2+Py3, so we have the mindset that
comprehension variables always leak.​
___
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] Python3 compiled listcomp can't see local var - bug or feature?

[Eric Fahlgren]

On Mon, Jun 11, 2018 at 3:10 PM Rob Cliffe via Python-Dev <
python-dev@python.org> wrote:

> Skip, I think you have misunderstood the  point I was making.  It was
> not whether the loop variable should leak out of a list comprehension.
> Rather, it was whether a local variable should, so to speak, "leak into"
> a list comprehension.  And the answer is: it depends on whether the code
> is executed normally, or via exec/eval.  Example:
>
> def Test():
>x = 1
>print([x+i for i in range(1,3)])  # Prints [2,3]
>exec('print([x+i for i in range(1,3)])') # Raises NameError (x)
> Test()
>
> I (at least at first) found the difference in behaviour surprising.
>

​Change 'def' to 'class' and run it again.  You'll be even more surprised.​
___
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] (Looking for) A Retrospective on the Move to Python 3

[Eric Fahlgren]

[esr]
> All this code runs under either 2 nor 3 without requiring six or any other
> shim library.

We've got an application that's about 500k loc, runs under both 2 and 3.
It has only one shim, a 'metaclass' decorator similar to what six provides,
other than that it's all quite clean 2- and 3-wise.

We long ago adopted "from __future__" as a standard part of every source
file, so we have internalized the Py3 print, division and import behaviors
as the norm.  An occasion scan with 2to3 kept us honest about
list-producing vs iterator-producing functions, and renamings and such.

Our major pain point was getting extension libraries that worked with 3,
notably VTK and wxPython, which weren't ported completely until last year.
We had been ready to switch over completely to Py3 almost four years ago,
but those major pieces were missing.  We have a production ready version
running under 3.6, but are going to wait for the 3.7 release before cutting
off support for Python 2 altogether.

Of note, we did not have any Unicode issues, as we adopted wxPython's
Unicode version as soon as it was available (6-7 years ago?), and had
virtually no issues then or since.
___
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] A fast startup patch (was: Python startup time)

[Eric Fahlgren]

On Sat, May 5, 2018 at 10:30 AM, Toshio Kuratomi  wrote:

> On Fri, May 4, 2018, 7:00 PM Nathaniel Smith  wrote:
>
>> What are the obstacles to including "preloaded" objects in regular .pyc
>> files, so that everyone can take advantage of this without rebuilding the
>> interpreter?
>>
>
> Would this make .pyc files arch specific?
>

Or have parallel "pyh" (Python "heap") files, that are architecture
specific... (But that would cost more stat calls.)
___
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: Assignment Expressions

[Eric Fahlgren]

On Tue, Apr 17, 2018 at 6:20 PM, Steven D'Aprano 
wrote:

> If there are tests which intentionally verify this behaviour, that
> really hurts your position that the behaviour is an accident of
> implementation. It sounds like the behaviour is intended and required.
>

​It is nonetheless bizarre and unexpected behavior.

>>> prefix = 'global'
>>> [prefix+c for c in 'abc']
['globala', 'globalb', 'globalc']

>>> def func():
... prefix = 'local'
... print([prefix+c for c in 'abc'])
>>> func()
['locala', 'localb', 'localc']

>>> class klass:
... prefix = 'classy'
... items = [prefix+c for c in 'abc']
>>> print(klass.items)
['globala', 'globalb', 'globalc']​

In Python 2, that last one would produce 'classya' and friends, due to the
"broken" comprehension scope.
___
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: Assignment Expressions

[Eric Fahlgren]

On Tue, Apr 17, 2018 at 2:23 AM, Chris Angelico  wrote:

> Augmented assignment is currently all of these:
>
> augassign: ('+=' | '-=' | '*=' | '@=' | '/=' | '%=' | '&=' | '|=' | '^=' |
> '<<=' | '>>=' | '**=' | '//=')
>
> I'm actually not sure whether the augmented-assignment-expression
> operators should be "+:=" or ":+=", but either way, it'd be another
> thirteen tokens, some of which would be *four* character tokens.
>

​Or simply rework the augmented assignment's semantics to become expression
operators without any syntactic changes.  Since there's no bug magnet
arising in the usual context where '=' and '==' get confused:

> if x += 1 < 2:
___
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] Sets, Dictionaries

[Eric Fahlgren]

On Thu, Mar 29, 2018 at 10:11 AM, David Mertz  wrote:

> I agree with everything Steven says. But it's true that even as a 20-year
> Python user, this is an error I make moderately often when I want an empty
> set... Notwithstanding that I typed it thousands of times before sets even
> existed (and still type it when I want an empty dictionary).
>
> That said, I've sort of got in the habit of using the type initializers:
>
> x = set()
> y = dict()
> z = list()
>
> I feel like those jump out a little better visually. But I'm inconsistent
> in my code.
>

​
Yeah, we've been doing that for several years, too.  A hair slower in some
cases, but much more greppable...

​
___
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] Guarantee ordered dict literals in v3.7?

[Eric Fahlgren]

On Thu, Dec 21, 2017 at 7:51 PM, Stephen J. Turnbull <
turnbull.stephen...@u.tsukuba.ac.jp> wrote:

> I understand the motivation to guarantee order, but it's a programmer
> convenience that has nothing to do with the idea of mapping, and the
> particular (insertion) order is very special and usually neither
> relevant nor reproducible.  I have no problem whatsoever with just
> documenting any failure to preserve order while reproducing dicts,
> *except* that a process that inserts keys in the same order had better
> result in the same insertion order.
>

​json, pickle == png, i.e., guaranteed lossless.
repr, pprint == jpg, lossy for very specific motivating reasons.​

In particular, I use pprint output in regression baselines, and if the long
documented sort-by-key behavior changed, I would not be happy.
___
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] f-strings

[Eric Fahlgren]

On Tue, Dec 19, 2017 at 8:47 AM, Stephen J. Turnbull <
turnbull.stephen...@u.tsukuba.ac.jp> wrote:

> If I were Bach, I'd compose a more-itertools-like module to be named
> Variations_on_the_F_String. :-)
>

​Would that be P.D.Q. Bach to whom you are referring?​
___
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?

[Eric Fahlgren]

On Fri, Dec 1, 2017 at 5:24 AM, Random832  wrote:

> You're completely missing the context of the discussion, which was the
> supposed reason that a *new* function call operator, with the proposed
> syntax function?(args), that would short-circuit (based on the
> 'function' being None) could not be implemented. The whole thing doesn't
> make sense to me anyway, since a new operator could have its own
> sequence different from the existing one if necessary.
>

​Right, I was clearly misinterpreting the wording in the PEP.  It's a bit
ambiguous and should probably make explicit that "evaluate the function"
isn't just the common vernacular for "call the function".
___
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?

[Eric Fahlgren]

On Thu, Nov 30, 2017 at 2:48 AM, Andrea Griffini  wrote:

> Not really related but the PEP says that arguments in Python are evaluated
> before the function (as a reason to reject the idea of None-aware function
> call) but this is not the case:
>

​I think you're missing something here, since it seems clear to me that
indeed the arguments are evaluated prior to the function call.​  Maybe
unrolling it would help?  This is equivalent to the body of your lambda,
and you can see that the argument is evaluated prior to the call which
receives it.

>>> func = f()
>>> arg = g()
>>> func(arg)

>>> import dis
> >>> dis.dis(lambda : f()(g()))
>   1   0 LOAD_GLOBAL  0 (f)
>   3 CALL_FUNCTION0
>

​Call 'f()' with all of its arguments evaluated prior to the call (there
are none, that's the '0' on the CALL_FUNCTION operator).
​


>   6 LOAD_GLOBAL  1 (g)
>   9 CALL_FUNCTION0
>

​Next, evaluate the arguments for the next function call.​
​  ​
​Call 'g()' with all of its arguments evaluated.
​

>  12 CALL_FUNCTION1
>

​Call the function that 'f()' returned with its argument ('g()') evaluated.
___
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 487: Simpler customization of class creation

[Eric Fahlgren]

On Wed 2016-06-22 Eric Snow [mailto:ericsnowcurren...@gmail.com] wrote:
> The problem I have with this is that it still doesn't give any strong 
> relationship with the class definition.
> Certainly in most cases it will amount to the same thing.  However, there is 
> no way to know if cls.__dict__ 
> represents the class definition or not.  You also lose knowing whether or not 
> a class came from a definition
> (or acts as though it did).  Finally, __definition_order__ makes the 
> relationship with the definition order clear,
>  whereas cls.__dict__ does not.
> Instead of being an obvious tool, with cls.__dict__ that relationship would 
> be tucked away where only a
>  few folks with deep knowledge of Python would be in a position to take 
> advantage.

I see this as being grossly/loosely analogous to traversing __bases__ vs 
calling mro(), so I feel the
same rationale applies to adding __definition_order__ as mro.

Eric

___
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] Wordcode: new regular bytecode using 16-bit units

[Eric Fahlgren]

Just on the off chance that it’s related, could it have something to do with 
the bug in findlabels?

 

http://bugs.python.org/issue26448

 

(I have high confidence that my patch fixes the problem, just haven’t gotten 
around to completing the tests.)

 

From: Demur Rumed [mailto:gunkm...@gmail.com] 
Sent: Saturday, April 16, 2016 17:05
To: python-dev@python.org
Subject: Re: [Python-Dev] Wordcode: new regular bytecode using 16-bit units

 

 The outstanding bug with this patch right now is a regression in line numbers 
causing the test for http://bugs.python.org/issue9936 to fail. I've tried to 
debug it without success

___
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] Wordcode: new regular bytecode using 16-bit units

[Eric Fahlgren]

The EXTENDED_ARG is included in the multibyte ops, I treat it just like any
other operator.  Here's a snippet of my hacked-dis.dis output, which made
it clear to me that I could just count them as an "operator with word
operand."

Line 3000: x = x if x or not x and x is None else x
0001dc83 7c 00 00 LOAD_FAST   x
0001dc86 91 01 00 EXTENDED_ARG1
0001dc89 70 9f dc JUMP_IF_TRUE_OR_POP L1dc9f
0001dc8c 7c 00 00 LOAD_FAST   x
0001dc8f 0c   UNARY_NOT
0001dc90 91 01 00 EXTENDED_ARG1
0001dc93 6f 9f dc JUMP_IF_FALSE_OR_POPL1dc9f
0001dc96 7c 00 00 LOAD_FAST   x
0001dc99 74 01 00 LOAD_GLOBAL None
0001dc9c 6b 08 00 COMPARE_OP  'is'
  L1dc9f:
0001dc9f 91 01 00 EXTENDED_ARG1
0001dca2 72 ab dc POP_JUMP_IF_FALSE   L1dcab
0001dca5 7c 00 00 LOAD_FAST   x
0001dca8 6e 03 00 JUMP_FORWARDL1dcae (+3)
  L1dcab:
0001dcab 7c 00 00 LOAD_FAST   x
  L1dcae:
0001dcae 7d 00 00 STORE_FAST  x


On Wed, Apr 13, 2016 at 2:23 PM, Victor Stinner <victor.stin...@gmail.com>
wrote:

> 2016-04-13 23:02 GMT+02:00 Eric Fahlgren <ericfahlg...@gmail.com>:
> > Percentage of 1-byte args= 96.80%
>
> Yeah, I expected such high ratio. Good news that you confirm it.
>
>
> > Non-argument ops =53,719
> > One-byte args=   368,787
> > Multi-byte args  =12,191
>
> Again, only a very few arguments take multiple bytes. Good, the
> bytecode will be smaller.
>
> IMHO it's more a nice side effect than a real goal. The runtime
> performance matters more than the size of the bytecode, it's not like
> a bytecode take 4 MB. It's probably closer to 1 KB and so can probably
> benefit of the fatest CPU caches.
>
>
> > Just for the record, here's my arithmetic:
> > byteCodeSize = 1*nonArgumentOps + 3*oneByteArgs + 3*multiByteArgs
> > wordCodeSize = 2*nonArgumentOps + 2*oneByteArgs + 4*multiByteArgs
>
> If multiByteArgs means any size > 1 byte, the wordCodeSize formula is
> wrong:
>
> - no parameter: 2 bytes
> - 8-bit parameter: 2 bytes
> - 16-bit parameter: 4 bytes
> - 24-bit parameter: 6 bytes
> - 32-bit parameter: 8 bytes
>
> But you wrote that you didn't see EXTEND_ARG, so I guess that
> multibyte means 16-bit in your case, and so your formula is correct.
>
> Hopefully, I don't expect 32-bit parameters in the wild, only 24-bit
> parameter for function with annotation.
>
>
> > (It is interesting to note that I have never encountered an EXTENDED_ARG
> operator in the wild, only in my own synthetic examples.)
>
> As I wrote, EXTENDED_ARG can be seen when MAKE_FUNCTION is used with
> annotations.
>
> Victor
>
___
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] Wordcode: new regular bytecode using 16-bit units

[Eric Fahlgren]

On Wednesday, April 13, 2016 09:25, Victor Stinner wrote:
> The side effect of wordcode is that arguments in 0..255 now uses 2 bytes per
> instruction instead of 3, so it also reduce the size of bytecode for the most
> common case.
> 
> Larger argument, 16-bit argument (0..65,535), now uses 4 bytes instead of 3.
> Arguments are supported up to 32-bit: 24-bit uses 3 units (6 bytes), 32-bit 
> uses 4
> units (8 bytes). MAKE_FUNCTION uses 16-bit argument for keyword defaults and
> 24-bit argument for annotations.
> Other common instruction known to use large argument are jumps for bytecode
> longer than 256 bytes.

A couple months ago during an earlier discussion of wordcode, I got curious 
enough to instrument dis.dis so that I could calculate the actual size changes 
expected in practice.  I ran it on a large chunk of our product code, here are 
the results (looks best with a fixed font).  I suspect the fairly significant 
reduction in footprint will also give better cache hit characteristics, so we 
might see some "magic" speed ups from that, too.

Code-generating source lines =70,792
Total bytes  = 1,196,653
Argument-bearing operators   =   380,978
Operands over 1 byte long=12,191
Extended arguments   = 0
Percentage of 1-byte args= 96.80%

Total operators  =   434,697
Non-argument ops =53,719
One-byte args=   368,787
Multi-byte args  =12,191
Byte code size   = 1,196,653
Word code size   =   893,776
Word:byte size   = 74.69%

Just for the record, here's my arithmetic:
byteCodeSize = 1*nonArgumentOps + 3*oneByteArgs + 3*multiByteArgs
wordCodeSize = 2*nonArgumentOps + 2*oneByteArgs + 4*multiByteArgs

(It is interesting to note that I have never encountered an EXTENDED_ARG 
operator in the wild, only in my own synthetic examples.)

___
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] When should pathlib stop being provisional?

[Eric Fahlgren]

On Wednesday, April 06, 2016 07:39,  Steven D'Aprano wrote:
> > How well does that apply to path/__path__?
> 
> I think it's potentially the same. Possibly there are fewer existing uses
of
> "obj.path" out there which conflict with this use, but there's at least
one in the
> std lib: sys.path.

Somewhat ironically, also os.

>>> import os.path
>>> getattr(os, "path")


___
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 Language Reference has no mention of list comÃprehensions

[Eric Fahlgren]

David R. Murray wrote: 
> I think the intuitive notion of "literal" is "the value is literally what is 
> written
> here".  Which is a redundant statement; 'as written' is, after all, what 
> literally
> means when used correctly :).  That makes it a language-agnostic concept if 
> I'm
> correct.

So { x : 1 } is not literally a literal, it's figuratively a literal, or more 
simply a figurative.

Eric

___
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] New Windows installer for Python 3.5

[Eric Fahlgren]

I believe that the new default location addresses your first question: the
64-bit will install in c:/Program Files/Pythonxx and the 32-bit in
c:/Program Files (x86)/Pythonxx (at least this has been my standard
practice for several years).

Eric
On Jan 4, 2015 7:03 AM, Paul Moore p.f.mo...@gmail.com wrote:

 On 3 January 2015 at 23:34, Steve Dower steve.do...@microsoft.com wrote:
  I've put together a short post showing where I've been taking the
 Windows installer for Python 3.5, since I know there are interested people
 on this list who will have valuable feedback.
 
  http://stevedower.id.au/blog/the-python-3-5-installer/
 
  Nothing is merged in yet and everything can still change, so I'm keen to
 hear whatever feedback people have. I've tried to make improvements fairly
 for first-time users through to sysadmins, but if I've missed something big
 I'd like to hear about it before we get too close to alpha 1.

 Overall, this looks good. One question - will it be possible to
 install both 32-bit and 64-bit Python on the same machine? Currently,
 you need a custom install to do this (as the default directory doesn't
 include the architecture) and IIRC there's some oddness around install
 order. It would be nice if installing both versions were a supported
 option, both for the default install and in custom installs.

 Also, what happens now with setting PATH? Is Python (and the scripts
 directory) added to PATH by default? If so, what happens when you
 install 2 versions of Python?

 In case it's not clear, I'm thinking of the impact on build machines,
 which often have multiple versions, in both 32- and 64-bit forms,
 installed simultaneously (but can also be used as a normal
 development machine, and for that purpose will want a selected Python
 version as the default one.

 Also, how does the launcher py.exe fit into the picture? Is it still
 installed into the Windows directory? What about for a user install?
 Are Python scripts associated with the launcher, and if so, how does
 it pick up the version you selected as default?

 (Sorry, that was more than one question :-))

 Paul
 ___
 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/ericfahlgren%40gmail.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