[Python-Dev] Re: Typing syntax and ecosystem, take 2

On 4/13/21 7:40 PM, Hugh Fisher wrote: From: Ned Batchelder [ munch ] This is very similar to statically typed languages. They also have two steps: * There is the first step that checks the types but does not run the program. In C/C++, this is the compiler, in Python it is "

[Python-Dev] Re: Typing syntax and ecosystem, take 2

On 4/12/21 7:43 PM, Hugh Fisher wrote: Having a type checker run before the Python interpreter in our current day continuous build/integration environment adds a second step This is very similar to statically typed languages. They also have two steps: * There is the first step that checks

[Python-Dev] Re: Non-monotonically increasing line numbers in dis.findlinestarts() output

On 3/17/21 6:41 PM, MRAB wrote: On 2021-03-17 22:10, Skip Montanaro wrote: I stumbled on this while trying to generate a line number table in my side project register VM. As I understand it, the line number delta in the output table is supposed to always be >= 0. In my code I'm using

[Python-Dev] Re: Please do not remove random bits of information from the tutorial

On 11/9/20 2:25 PM, Raymond Hettinger wrote: On Nov 7, 2020, at 9:51 AM, Riccardo Polignieri via Python-Dev wrote: My concern here is that if you start removing or simplifying some "too-difficult-for-a-tutorial" bits of information on an occasional basis, and without too much scrutiny or

[Python-Dev] Re: Please do not remove random bits of information from the tutorial

I think when Riccardo said "The PEPs are the worst," he meant that PEPs do not work well as documentation for features, because it was not their purpose.  PEPs are designed to be proposals, and then summaries of decisions.  I agree with him that linking to PEPs should be for supporting

[Python-Dev] Re: PEP 626: Precise line numbers for debugging and other tools.

On 7/17/20 10:48 AM, Mark Shannon wrote: Hi all, I'd like to announce a new PEP. It is mainly codifying that Python should do what you probably already thought it did :) Should be uncontroversial, but all comments are welcome. Thanks for thinking about these aspects of the interpreter,

[Python-Dev] Re: PEP 626: Precise line numbers for debugging and other tools.

On 7/22/20 6:42 AM, Inada Naoki wrote: On Wed, Jul 22, 2020 at 6:12 PM Antoine Pitrou > wrote: > > > > > But if we merge two equal code blocks, we can not produce precise line > > numbers, can we? > > Is this inconsistent microoptimization that real optimization

[Python-Dev] Re: PEP 626: Precise line numbers for debugging and other tools.

On 7/21/20 5:04 PM, Gregory P. Smith wrote: Given it is impossible for tools doing passive inspection of Python VM instances to execute code, co_linetable's exact format will be depended on just as co_lnotab was.  co_lnotab was only quasi-"officially" documented in the Python docs, it's spec

[Python-Dev] Re: PEP 626: Precise line numbers for debugging and other tools.

https://www.python.org/dev/peps/pep-0626/ :) --Ned. On 7/17/20 10:48 AM, Mark Shannon wrote: Hi all, I'd like to announce a new PEP. It is mainly codifying that Python should do what you probably already thought it did :) Should be uncontroversial, but all comments are welcome. Cheers,

[Python-Dev] Re: Comments on PEP 554 (Multiple Interpreters in the Stdlib)

On 4/21/20 12:32 PM, Mark Shannon wrote: Hi, I'm generally in favour of PEP 554, but I don't think it is ready to be accepted in its current form. BTW, thanks for including the name of the PEP in the subject.  As a casual reader of this list, it's very helpful to have more than just the

[Python-Dev] Re: Any thoughts about a control flow optimizer for CPython?

BTW, so that we don't have to completely retrace our steps, this topic was also discussed in depth on Python-Ideas in May 2014: https://mail.python.org/archives/list/python-id...@python.org/thread/X6VCB2E4EHOLUWHO42FYUT6VDAFNUHJF/ --Ned. On 4/6/20 6:56 AM, Ned Batchelder wrote: On 4/6/20 5

[Python-Dev] Re: Any thoughts about a control flow optimizer for CPython?

On 4/6/20 5:41 AM, Mark Shannon wrote: Hi, On 05/04/2020 12:47 pm, Ned Batchelder wrote: On 4/3/20 11:13 AM, joannah nanjekye wrote: Hey all, From my CS theory, a control flow graph models a program flow and one of its main characteristics is it has one entry and exit point. IIRC, CPython’s

[Python-Dev] Re: Any thoughts about a control flow optimizer for CPython?

On 4/3/20 11:13 AM, joannah nanjekye wrote: Hey all, From my CS theory, a control flow graph models a program flow and one of its main characteristics is it has one entry and exit point. IIRC, CPython’s compilation process involves generation of a control flow graph. Contrary to peephole

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

On 3/21/20 12:51 PM, Rob Cliffe via Python-Dev wrote: On 21/03/2020 16:15, Eric V. Smith wrote: On 3/21/2020 11:20 AM, Ned Batchelder wrote: On 3/20/20 9:34 PM, Cameron Simpson wrote: On 20Mar2020 13:57, Eric Fahlgren wrote: On Fri, Mar 20, 2020 at 11:56 AM Dennis Sweeney wrote: If ``s

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

On 3/20/20 9:34 PM, Cameron Simpson wrote: On 20Mar2020 13:57, Eric Fahlgren wrote: 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

[Python-Dev] Re: Deprecating the "u" string literal prefix

On 12/3/19 1:07 PM, Ethan Furman wrote: On 12/03/2019 09:16 AM, Serhiy Storchaka wrote: The 'u" string literal prefix was removed in 3.0 and reintroduced in 3.3 to help writing the code compatible with Python 2 and 3 [1]. After the dead of Python 2.7 we will remove some deprecated features

[Python-Dev] Re: Deprecating the "u" string literal prefix

On 12/4/19 3:11 AM, Serhiy Storchaka wrote: 04.12.19 04:41, Ned Batchelder пише: On 12/3/19 8:13 PM, Inada Naoki wrote: I think it is too early to determine when to remove it. Even only talking about it causes blaming war. Has anyone yet given a reason to remove it? It will change working

[Python-Dev] Re: Deprecating the "u" string literal prefix

On 12/3/19 8:13 PM, Inada Naoki wrote: I think it is too early to determine when to remove it. Even only talking about it causes blaming war. Has anyone yet given a reason to remove it? It will change working code into broken code. Why do that? --Ned. BTW, I think 2to3 can help to move

[Python-Dev] Re: Deprecating the "u" string literal prefix

On 12/3/19 12:16 PM, Serhiy Storchaka wrote: The 'u" string literal prefix was removed in 3.0 and reintroduced in 3.3 to help writing the code compatible with Python 2 and 3 [1]. After the dead of Python 2.7 we will remove some deprecated features kept for compatibility with 2.7. When we are

[Python-Dev] Re: Deprecating the "u" string literal prefix

On 12/3/19 2:41 PM, Christian Heimes wrote: On 03/12/2019 19.09, Barry Warsaw wrote: On Dec 3, 2019, at 09:16, Serhiy Storchaka wrote: The 'u" string literal prefix was removed in 3.0 and reintroduced in 3.3 to help writing the code compatible with Python 2 and 3 [1]. After the dead of Python

[Python-Dev] Re: The Python 2 death march

On 9/10/19 11:06 AM, Benjamin Peterson wrote: On Tue, Sep 10, 2019, at 15:54, Ned Batchelder wrote: Maybe I'm not involved enough in the release process, but this seems confusing to me.  On the same day that the PSF put up a page about the 1/1/2020 date, we choose April 2020 as the last release

[Python-Dev] Re: The Python 2 death march

Maybe I'm not involved enough in the release process, but this seems confusing to me.  On the same day that the PSF put up a page about the 1/1/2020 date, we choose April 2020 as the last release?  Why?  I thought the point was to save core devs efforts.  Is this an unofficial grace period? 

[Python-Dev] Re: Removing dead bytecode vs reporting syntax errors

      try:             pass         except Exception:             yield 3     """) See also the doc: https://fatoptimizer.readthedocs.io/en/latest/optimizations.html#dead-code -- About code coverage, it seems like -X noopt would help: https:

Re: [Python-Dev] PEP 594: Removing dead batteries from the standard library

On 5/21/19 8:37 AM, Christian Heimes wrote: On 21/05/2019 14.06, Anders Munch wrote: Fra: Python-Dev [mailto:python-dev-bounces+ajm=flonidan...@python.org] På vegne af Christian Heimes * The removed modules will be available through PyPI. Will they? That's not the impression I got from the

Re: [Python-Dev] Is XML serialization output guaranteed to be bytewise identical forever?

On 3/19/19 4:13 AM, Serhiy Storchaka wrote: 19.03.19 00:41, Raymond Hettinger пише: 3) Add a standards compliant canonicalization tool (see https://en.wikipedia.org/wiki/Canonical_XML ).  This is likely to be the right-way-to-do-it but takes time and energy. 4) Fix the tests in the

Re: [Python-Dev] (name := expression) doesn't fit the narrative of PEP 20

On 4/27/18 5:28 PM, Tres Seaver wrote: On 04/27/2018 05:11 PM, Tim Peters wrote: In this specific case, line-oriented coverage tools have missed accounting for all possible code paths since day #1; e.g., x = f() or g() You don't need to reply to messages so obviously irrelevant to the PEP

Re: [Python-Dev] Is static typing still optional?

On 12/29/17 1:59 PM, Guido van Rossum wrote: Regarding whether this should live on PyPI first, in this case that would not be helpful, since attrs is already the category killer on PyPI. So we are IMO taking the best course possible given that we want something in the stdlib but not exactly

Re: [Python-Dev] Is static typing still optional?

On 12/26/17 1:49 PM, Chris Barker wrote: On Sat, Dec 23, 2017 at 5:54 PM, Nick Coghlan > wrote: I still wonder about the "fields *must* be annotated" constraint though. I can understand a constraint that the style be *consistent*

Re: [Python-Dev] 3.5 unittest does not support namespace packages for discovering

On 3/23/17 3:14 PM, Robert Collins wrote: > On 24 March 2017 at 04:59, INADA Naoki wrote: >> And this issue is relating to it too: http://bugs.python.org/issue29716 >> >> In short, "namespace package" is for make it possible to `pip install >> foo_bar foo_baz`, >> when

Re: [Python-Dev] Recent changes to PyCodeObject

On 11/17/16 10:09 AM, Cody Piersall wrote: > On Wed, Nov 16, 2016 at 6:18 PM, Ned Batchelder <n...@nedbatchelder.com> > wrote: >> When I added Python 3.6 support to coverage.py, I posted a Mac wheel to >> PyPI: https://pypi.python.org/pypi/coverage/ That wheel wa

[Python-Dev] Recent changes to PyCodeObject

When I added Python 3.6 support to coverage.py, I posted a Mac wheel to PyPI: https://pypi.python.org/pypi/coverage/ That wheel was built against 3.6a3, the latest version at the time. When I use it now on 3.6b3, it doesn't work right. The reason is that the co_firstlineno field in PyCodeObject

Re: [Python-Dev] Is there a reference manual for Python bytecode?

On 12/26/15 10:19 PM, Nick Coghlan wrote: On 27 December 2015 at 12:23, Guido van Rossum wrote: On Sat, Dec 26, 2015 at 6:06 PM, Brett Cannon wrote: Ned also neglected to mention his byterun project which is a pure Python implementation of the CPython

Re: [Python-Dev] Is there a reference manual for Python bytecode?

On 12/26/15 6:13 PM, Erik wrote: On 26/12/15 23:10, Joe Jevnik wrote: All arguments are 2 bytes, if there needs to be more, EXTENDED_ARG is used OK, got it - many thanks. One thing to understand that may not be immediately apparent: the byte code can (and does) change between versions, so

Re: [Python-Dev] cpython (3.5): remove STORE_MAP, since it's unused

On 5/28/15 3:52 PM, Serhiy Storchaka wrote: On 28.05.15 22:40, benjamin.peterson wrote: https://hg.python.org/cpython/rev/ac891c518d4e changeset: 96342:ac891c518d4e branch: 3.5 parent: 96339:6f05f83c7010 user:Benjamin Peterson benja...@python.org date:Thu May 28

[Python-Dev] Issue 24285: regression for importing extensions in packages

This issue has been fixed, but a day or two late for 3.5b1. It prevents loading the coverage.py extension. It'd be great to get a new beta release soon. :) --Ned. ___ Python-Dev mailing list Python-Dev@python.org

Re: [Python-Dev] The pysandbox project is broken

On 11/12/13 6:48 PM, Terry Reedy wrote: On 11/12/2013 4:16 PM, Victor Stinner wrote: It would also be nice to help developers looking for a sandbox for their application. Please tell me if you know sandbox projects for Python so I can redirect users of pysandbox to a safer solution. I already

[Python-Dev] PEPs shouldn't be considered docs

I wanted to teach a co-worker about from __future__ import absolute_import today, so I thought I'd point them at the docs. The page for __future__ starts with a bunch of internal details that almost no one needs to know. There's a table at the end that mentions the actual importable names,

Re: [Python-Dev] cpython: Use cached builtins.

On 10/2/13 1:31 PM, Antoine Pitrou wrote: On Wed, 2 Oct 2013 18:16:48 +0200 (CEST) serhiy.storchaka python-check...@python.org wrote: http://hg.python.org/cpython/rev/d48ac94e365f changeset: 85931:d48ac94e365f user:Serhiy Storchaka storch...@gmail.com date:Wed Oct 02 19:15:54

Re: [Python-Dev] Why not support user defined operator overloading ?

On 9/29/13 11:06 AM, Xavier Morel wrote: This is more of a python-ideas subject. And one of the reasons likely is that it would require significantly reworking the grammar to handle a kind of user-defined opname (similar to name, but for operator tokens), with user-defined priority and

Re: [Python-Dev] Why not support user defined operator overloading ?

On 9/29/13 9:02 PM, 张佩佩 wrote: On 2013/9/30 8:53 Greg Ewing wrote: It does need to know the operator's precedence and associativity, though, which means either declaring it somewhere, or having some kind of fixed rule I suggest all user defined operator are at lowest priority. Peipei, this

Re: [Python-Dev] Purpose of Doctests [Was: Best practices for Enum]

On 5/19/2013 7:22 PM, Mark Janssen wrote: On Sun, May 19, 2013 at 1:13 PM, Tres Seaver tsea...@palladion.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/19/2013 10:48 AM, Guido van Rossum wrote: Anyway, if you're doing arithmetic on enums you're doing it wrong. Hmm, bitwise

Re: [Python-Dev] Usage of += on strings in loops in stdlib

On 2/12/2013 4:16 PM, Brett Cannon wrote: On Tue, Feb 12, 2013 at 4:06 PM, Antoine Pitrou solip...@pitrou.net mailto:solip...@pitrou.net wrote: Hi ! On Tue, 12 Feb 2013 23:03:04 +0200 Maciej Fijalkowski fij...@gmail.com mailto:fij...@gmail.com wrote: We recently

Re: [Python-Dev] Do more at compile time; less at runtime

On 12/9/2012 5:22 PM, Mark Shannon wrote: The current CPython bytecode interpreter is rather more complex than it needs to be. A number of bytecodes could be eliminated and a few more simplified by moving the work involved in handling compound statements (loops, try-blocks, etc) from the

Re: [Python-Dev] chained assignment weirdity

On 11/6/2012 5:12 PM, Guido van Rossum wrote: On Tue, Nov 6, 2012 at 9:58 AM, Ned Batchelder n...@nedbatchelder.com wrote: On 11/6/2012 11:26 AM, R. David Murray wrote: On Tue, 06 Nov 2012 18:14:38 +0200, Serhiy Storchaka storch...@gmail.com wrote: Another counterintuitive (and possible

Re: [Python-Dev] chained assignment weirdity

On 11/7/2012 12:08 PM, Serhiy Storchaka wrote: On 07.11.12 17:12, Nick Coghlan wrote: Since you've indicated the implementation is in the wrong here and you also want to preserve opcode semantics, I think Skip's patch is correct, but also needs to be applied to dict comprehensions (now we have

Re: [Python-Dev] chained assignment weirdity

On 11/7/2012 5:11 PM, Terry Reedy wrote: On 11/7/2012 4:39 PM, Ned Batchelder wrote: Just to be clear: the reference guide says that the behavior *SHOULD BE* (but is not yet) this: Python 3.3.0 {print(a):print(b)} a b {None: None} d = {} d[print(a)] = print(b

Re: [Python-Dev] chained assignment weirdity

On 11/6/2012 11:26 AM, R. David Murray wrote: On Tue, 06 Nov 2012 18:14:38 +0200, Serhiy Storchaka storch...@gmail.com wrote: Another counterintuitive (and possible wrong) example: {print('foo'): print('bar')} bar foo {None: None} http://bugs.python.org/issue11205 This

Re: [Python-Dev] chained assignment weirdity

On 11/6/2012 1:19 PM, Devin Jeanpierre wrote: On Nov 6, 2012 1:05 PM, Ned Batchelder n...@nedbatchelder.com mailto:n...@nedbatchelder.com wrote: On 11/6/2012 11:26 AM, R. David Murray wrote: On Tue, 06 Nov 2012 18:14:38 +0200, Serhiy Storchaka storch...@gmail.com mailto:storch

Re: [Python-Dev] Python Bug Day in October

On 9/27/2012 6:30 PM, Éric Araujo wrote: Hi all, The Montreal-Python user group would like to host a bug day on October 27 (to be confirmed) at a partner university in Montreal. It would be cool to do a bug day on IRC like we used to (and in other physical locations if people want to!) to get

Re: [Python-Dev] AST optimizer implemented in Python

On 8/11/2012 2:30 PM, Victor Stinner wrote: Hi, I started to implement an AST optimizer in Python. It's easy to create a new AST tree, so I'm surprised that I didn't find any existing project. https://bitbucket.org/haypo/misc/src/tip/python/ast_optimizer.py To test its peephole optimizations

Re: [Python-Dev] Playing with a new theme for the docs, iteration 2

On 3/25/2012 2:34 AM, Georg Brandl wrote: Here's another try, mainly with default browser font size, more contrast and collapsible sidebar again: http://www.python.org/~gbrandl/build/html2/ Georg, thanks so much for taking on this thankless task with grace and skill. It can't be easy dealing

Re: [Python-Dev] Playing with a new theme for the docs

On 3/21/2012 6:16 AM, Oleg Broytman wrote: On Wed, Mar 21, 2012 at 09:33:13AM +, Jonathan Hartley wrote: On 21/03/2012 08:25, Dirkjan Ochtman wrote: On Wed, Mar 21, 2012 at 07:00, Georg Brandlg.bra...@gmx.net wrote: OK, that seems to be the main point people make... let me see if I can

Re: [Python-Dev] Playing with a new theme for the docs

On 3/21/2012 9:44 AM, Serhiy Storchaka wrote: 21.03.12 03:58, Ned Batchelder написав(ла): Books, magazines, and newspapers look good with full justification, web pages do not. Can we switch to left-justified instead? You can add line p {text-align: left !important} to your browser custom

Re: [Python-Dev] Playing with a new theme for the docs

On 3/21/2012 1:04 PM, Serhiy Storchaka wrote: If I can get my five cents, I will tell about my impressions. I really liked the background of allocated blocks (such as notes and code snippets) has become less diverse (but still visible). The border around these blocks have become more accurate

Re: [Python-Dev] Playing with a new theme for the docs

On 3/21/2012 2:46 PM, Guido van Rossum wrote: On Wed, Mar 21, 2012 at 11:40 AM, Ned Batcheldern...@nedbatchelder.com wrote: You can use Ctrl-+ to increase the size of the text, and modern browsers remember that for the next time you visit the site. That doesn't mean the web designer shouldn't

Re: [Python-Dev] Playing with a new theme for the docs

On 3/21/2012 3:06 PM, Fred Drake wrote: On Wed, Mar 21, 2012 at 2:46 PM, Guido van Rossumgu...@python.org wrote: That doesn't mean the web designer shouldn't think at least twice before specifying a smaller font than the browser default. Yet 90% of designers (or more) insist on making text

Re: [Python-Dev] Playing with a new theme for the docs

On 3/21/2012 3:45 PM, Ethan Furman wrote: Guido van Rossum wrote: On Wed, Mar 21, 2012 at 7:18 AM, Ned Batchelder n...@nedbatchelder.com wrote: The challenge for the maintainer of the docs site is to choose a good design that most people will see. We're bound to disagree on what that design

Re: [Python-Dev] Playing with a new theme for the docs

On 3/21/2012 4:38 PM, Fred Drake wrote: On Wed, Mar 21, 2012 at 3:13 PM, Ned Batcheldern...@nedbatchelder.com wrote: There are bad designers, or more to the point, designers who favor the overall look of the page at the expense of the utility of the page. That doesn't mean all designers are

Re: [Python-Dev] Playing with a new theme for the docs

On 3/20/2012 6:38 PM, Georg Brandl wrote: Let me know what you think, or play around and send some improvements. (The collapsible sidebar is not adapted to it yet, but will definitely be integrated before I consider applying a new theme to the real docs.) Not to add to the chorus of tweakers,

Re: [Python-Dev] [RELEASED] Python 3.3.0 alpha 1

On 3/5/2012 2:54 AM, Georg Brandl wrote: On behalf of the Python development team, I'm happy to announce the first alpha release of Python 3.3.0. This is a preview release, and its use is not recommended in production settings. Python 3.3 includes a range of improvements of the 3.x series, as

Re: [Python-Dev] PEP 414

On 2/26/2012 6:14 AM, Nick Coghlan wrote: As soon as you allow the use of from __future__ import unicode_literals or a module level __metaclass__ = type, you can't review diffs in isolation any more - whether the diff is correct or not will depend on the presence or absence of module level tweak

Re: [Python-Dev] Status regarding Old vs. Advanced String Formating

On 2/24/2012 7:23 PM, Mark Lawrence wrote: I think this is daft because all of the code has to be supported for the ten years that MVL has suggested. I suggest a plan that says something like:- Until Python 3.5 both methods of string formatting will be supported. In Python 3.6 the the old

Re: [Python-Dev] PEP 7 clarification request: braces

On 1/1/2012 11:44 PM, Nick Coghlan wrote: I've been having an occasional argument with Benjamin regarding braces in 4-line if statements: if (cond) statement; else statement; vs. if (cond) { statement; } else { statement; } He keeps leaving them out, I

Re: [Python-Dev] PEP 7 clarification request: braces

On 1/2/2012 5:32 PM, Raymond Hettinger wrote: Running ``grep -B1 else Objects/*c`` shows that we've happily lived with a mixture of styles for a very long time. ISTM, our committers have had good instincts about when braces add clarity and when they add clutter. If Nick pushes through an

Re: [Python-Dev] Hash collision security issue (now public)

On 12/28/2011 9:09 PM, Raymond Hettinger wrote: Also, randomizing the hash wreaks havoc on doctests, book examples not matching actual dict reprs, and on efforts by users to optimize the insertion order into dicts with frequent lookups. I don't have a strong opinion about what to do about this

Re: [Python-Dev] Python 3 optimizations continued...

On 8/30/2011 4:41 PM, stefan brunthaler wrote: Ok, there there's something else you haven't told us. Are you saying that the original (old) bytecode is still used (and hence written to and read from .pyc files)? Short answer: yes. Long answer: I added an invocation counter to the code object

Re: [Python-Dev] Commit messages: please avoid temporal ambiguity

On 5/9/2011 1:24 PM, Terry Reedy wrote: A commit (push) partition time and behavior into before and after (with a short change period in between during which behavior is undefined). Some commit messages have the form 'x does y'. Does 'does' mean before or after? Sometimes that is clear. 'x

Re: [Python-Dev] sys.settrace: behavior doesn't match docs

Indeed, the 2.0 code is very different, and got this case right. I'm a little surprised no one is arguing that changing this code now could break some applications. Maybe the fact no one noticed the docs were wrong proves that no one ever tried returning None from a local trace function.

[Python-Dev] sys.settrace: behavior doesn't match docs

This week I learned something new about trace functions (how to write a C trace function that survives a sys.settrace(sys.gettrace()) round-trip), and while writing up what I learned, I was surprised to discover that trace functions don't behave the way I thought, or the way the docs say they

Re: [Python-Dev] Suggest reverting today's checkin (recursive constant folding in the peephole optimizer)

On 3/12/2011 12:39 AM, Eugene Toder wrote: You've got wishful thinking if you think a handful of tests can catch errors in code that sophisticated. Why limit yourself with a handful of tests? Python is widespread, there's*a lot* of code in Python. Unlike with libraries, any code you run

Re: [Python-Dev] Possible optimization for LOAD_FAST ?

On 1/2/2011 8:17 AM, Victor Stinner wrote: Le mercredi 29 décembre 2010 à 14:20 +0100, Martin v. Löwis a écrit : Am 28.12.2010 18:08, schrieb Lukas Lueg: Also, the load_fast in lne 22 to reference x could be taken out of the loop as x will always point to the same object That's not true;

Re: [Python-Dev] Possible optimization for LOAD_FAST ?

On 12/31/2010 12:51 PM, Cesare Di Mauro wrote: 2010/12/31 s...@pobox.com mailto:s...@pobox.com Another example. I can totally remove the variable i, just using the stack, so a debugger (or, in general, having the tracing enabled) cannot even find something to change about

Re: [Python-Dev] os.path.normcase rationale?

On 9/24/2010 6:13 AM, Chris Withers wrote: On 18/09/2010 23:36, Guido van Rossum wrote: course, exists() and isdir() etc. do, and so does realpath(), but the pure parsing functions don't. Yes, but: H:\echo foo TeSt.txt ... import os.path os.path.realpath('test.txt') 'H:\\test.txt'