[Python-Dev] Re: Mixed Python/C debugging

Python Tools for Visual Studio has supported mixed mode debugging for a while... I'm not sure if that support would have ever ended up in VS Code Python extension so it might be a windows only solution which might not help you much. On Sun, Dec 1, 2019, 9:04 AM Skip Montanaro wrote: > Having

Re: [Python-Dev] Register-based VM [Was: Possible performance regression]

On Tue, Feb 26, 2019 at 3:56 PM Neil Schemenauer wrote: > Right. I wonder though, could we avoid allocating the Python frame > object until we actually need it? Two situations when you need a > heap allocated frame come to mind immediately: generators that are > suspended and frames as part of

Re: [Python-Dev] Experiment an opt-in new C API for Python? (leave current API unchanged)

> > That's exactly why I dislike "New", it's like adding "Ex" or "2" to a > function name :-) > > Well, before bikeshedding on the C define name, I would prefer to see > if the overall idea of trying to push code for the new C API in the > master branch is a good idea, or if it's too early and the

Re: [Python-Dev] Update on PEP 523 and adding a co_extra field to code objects

So it looks like both list and tuple are about within 5% of using co_extra directly. Using a tuple instead of a list is about a wash except for make_v2 where list is 1.4x slower for some reason (which I didn't dig into). I would say that using a tuple and copying the tuple on updates makes

Re: [Python-Dev] Update on PEP 523 and adding a co_extra field to code objects

So I ran the tests with both a list and a tuple. They were about 5% slower on a handful of benchmarks, and then the difference between the tuple and list again had a few benchmarks that were around 5% slower. There was one benchmark where the tuple one significantly for some reason (mako_v2)

Re: [Python-Dev] frame evaluation API PEP

On Mon, Jun 20, 2016 at 12:59 PM, Brett Cannon > wrote: MRAB's response made me think of a possible approach: the co_extra field could be the very last field of the PyCodeObject struct and only present if a certain flag is set in co_flags. This is

Re: [Python-Dev] frame evaluation API PEP

Mark wrote: > > Dino and I thought of two potential alternatives, neither of which we > > have taken the time to implement and benchmark. One is to simply have > > a hash table of memory addresses to JIT data that is kept on the JIT > > side of things. Obviously it would be nice to avoid the

Re: [Python-Dev] C99

Martin wrote: > On 4 June 2016 at 06:11, Benjamin Peterson wrote: > > PEP 7 requires CPython to use C code conforming to the venerable C89 > > standard. Traditionally, we've been stuck with C89 due to poor C > > support in MSVC. However, MSVC 2013 and 2015 implement the key

Re: [Python-Dev] More compact dictionaries with faster iteration

PJ wrote: Actually, IronPython may already have ordered dictionaries by default; see: http://mail.python.org/pipermail/ironpython-users/2006- May/002319.html It's described as an implementation detail that may change, perhaps that could be changed to being unchanging. ;-) I think

[Python-Dev] yield from, user defined iterators, and StopIteration w/ a value...

I'm trying to create an object which works like a generator and delegates to a generator for its implementation, but can also participate in yield from using 3.3 beta. I want my wrapper object to be able to cache some additional information - such as whether or not the generator has completed

Re: [Python-Dev] Python as a Metro-style App

Dino wrote: Martin wrote: See the start of the thread: I tried to create a WinRT Component DLL, and that failed, as VS would refuse to compile any C file in such a project. Not sure whether this is triggered by defining WINAPI_FAMILY=2, or any other compiler setting. I'd really love

Re: [Python-Dev] Python as a Metro-style App

Martin wrote: See the start of the thread: I tried to create a WinRT Component DLL, and that failed, as VS would refuse to compile any C file in such a project. Not sure whether this is triggered by defining WINAPI_FAMILY=2, or any other compiler setting. I'd really love to use

Re: [Python-Dev] Python as a Metro-style App

Martin wrote: Does that hold for all versions of the C runtime (i.e. is msvcr80.dll also exempt from the ban, or just the version that comes with VS 11)? Just the VS 11 CRT is allowed. So to the extent that Python is just a C program the port should be pretty easy and mostly involve

Re: [Python-Dev] Python as a Metro-style App

: python-dev@python.org; Dino Viehland Subject: Re: [Python-Dev] Python as a Metro-style App On Sat, Jan 7, 2012 at 2:57 PM, Antoine Pitrou solip...@pitrou.net wrote: Depending on the extent of removed/disabled functionality, it might not be very interesting to have a Metro port at all. Win 8

Re: [Python-Dev] PEP 393 Summer of Code Project

Guido wrote: Which reminds me. The PEP does not say what other Python implementations besides CPython should do. presumably Jython and IronPython will continue to use UTF-16, so presumably the language reference will still have to document that strings contain code units (not code points)

Re: [Python-Dev] Policy for making changes to the AST

Guido wrote: On Mon, Apr 4, 2011 at 10:05 AM, fwierzbi...@gmail.com fwierzbi...@gmail.com wrote: As a re-implementor of ast.py that tries to be node for node compatible, I'm fine with #1 but would really like to have tests that will fail in test_ast.py to alert me! [and] On Mon, Apr

Re: [Python-Dev] Policy for making changes to the AST

Terry wrote: Are at least some of the implementation methods similar enough that they could use the same AST? It is, after all, a *semantic* translation into another language, and that need not depend on subsequent transforation and compilation to the ultimate target. A

Re: [Python-Dev] A grammatical oddity: trailing commas in argument lists.

Terry wrote: This violates the important principle that allowed def and call arg sequences should match to the extent sensible and possible. In this sense, the SyntaxError is a bug. So I would fix this now for 3.2 and notify the other implementors. +1 on fixing it - trailing commas are

Re: [Python-Dev] Very Strange Argument Handling Behavior

Benjamin wrote: 2010/4/17 Guido van Rossum gu...@python.org: On Sat, Apr 17, 2010 at 9:22 AM, Nick Coghlan ncogh...@gmail.com wrote: Guido van Rossum wrote: Because Python promises that the object the callee sees as 'kwargs' is just a dict. Huh, I thought kwargs was allowed to be

Re: [Python-Dev] Very Strange Argument Handling Behavior

Maciej wrote: On Sat, Apr 17, 2010 at 11:38 AM, Dino Viehland di...@microsoft.com wrote: Benjamin wrote: 2010/4/17 Guido van Rossum gu...@python.org: On Sat, Apr 17, 2010 at 9:22 AM, Nick Coghlan ncogh...@gmail.com wrote: Guido van Rossum wrote: Because Python promises

Re: [Python-Dev] Very Strange Argument Handling Behavior

Mark Dickinson wrote: Removing it certainly seems in keeping with the goal of making life easier for alternate implementations. (Out of curiosity, does anyone know what IronPython does here?) I've opened http://bugs.python.org/issue8419 It looks like IronPython reports a type error as

Re: [Python-Dev] First draft of sysconfig

Tarek wrote: How would you use it when a list is returned ? Can you provide a few examples where the code wants to know the default architecture for the current platform ? etc. The consumer could enumerate over it and then do whatever they were doing w/ the platform multiple times. If an

Re: [Python-Dev] First draft of sysconfig

Tarek wrote: == Installation schemes == First, the module contains the installation schemes for each platform CPython uses. An install scheme is a mapping where the key is the code name for a directory, and the value the path of that directory, with some $variable that can be expanded.

[Python-Dev] Microsoft contributor agreement received?

I'm not sure the best place to verify this so I'm starting here. I'm told we finally faxed in our contributor agreement (to the number listed at http://www.python.org/psf/contrib/) about a week and a half ago. I'd just like to make sure that someone has received it. Is anyone here able to

Re: [Python-Dev] First draft of sysconfig

Tarek wrote: (I didn't digg on how Jython organizes things yet, any hint would be appreciated) The installation directory looks like it's organized just like CPython but I have no clue how user directories would/should be arranged. Also if the purpose of this is for platform specific

Re: [Python-Dev] First draft of sysconfig

Antoine wrote: Dino Viehland dinov at microsoft.com writes: * get_platform(): Return a string that identifies the current platform. (this one is used by site.py for example) I wonder if this would make more sense a built-in. Ultimately it seems like the interpreter implementation

Re: [Python-Dev] PEP 3003 - Python Language Moratorium

Stefan wrote: I assume that this is artificially exaggerated to make a point, as this behaviour is obviously not a technical requirement but an optimisation, which could potentially be disabled. If there's a way to disable this then that's fine and IMO when it was disabled you'd still be

Re: [Python-Dev] PEP 370 and IronPython

Michael wrote: The IronPython team currently have legal issues distributing modified versions of the standard library (Dino can correct me if I'm wrong here). It's actually not due to legal issues although we'd have to check w/ the lawyers if we wanted to do it. It's mainly that we don't

Re: [Python-Dev] PEP about sys.implementation and implementation specific user site directory

Christian wrote: sys.implementation is a PyStructSequence that contains various information about the current implementation. Some fields are required to be present on every implementation. Implementations may choose to add additional fields as they see fit. Some fields like compiler are

Re: [Python-Dev] PEP about sys.implementation and implementation specific user site directory

Christian wrote: Martin has already answered both points to my satisfaction. Do you agree with him? Sure, source level makes more sense - so we'd have csc or gmcs if compiled with Mono (assuming there's some way to do that...). ___ Python-Dev

Re: [Python-Dev] operator precedence of __eq__, __ne__, etc, if both object have implementations

Skip wrote: Dino For IronPython we wrote a set of tests which go through and define Dino the various operator methods in all sorts of combinations on both Dino new-style and old-style classes as well as subclasses of those Dino classes and then do the comparisons w/ logging.

Re: [Python-Dev] operator precedence of __eq__, __ne__, etc, if both object have implementations

Mark wrote: On Wed, Sep 23, 2009 at 4:54 PM, Dino Viehland di...@microsoft.com wrote: We are going to start contributing tests back real soon now.  I'm not sure that these are the best tests to contribute as they require a version of Python to compare against rather than being nice

Re: [Python-Dev] unsubscriptable vs object does not support indexing

Brett wrote: Let's ignore history, which I bet is the reason for the distinction, and just look at the error messages; does the distinction make sense to a newbie? I would say no and that the does not support indexing error message is more useful. For expert programmers they could figure out

[Python-Dev] unsubscriptable vs object does not support indexing

Is there a reason or a rule by which CPython reports different error message for different failures to subscript? For example: set()[2] Traceback (most recent call last): File stdin, line 1, in module TypeError: 'set' object does not support indexing class c(object): pass ... c()[2]

Re: [Python-Dev] unsubscriptable vs object does not support indexing

R. David Murray wrote: Looking at the source, these messages are generated from abstract.c, and the difference appears to be whether or not the tp_as_sequence slot is filled in or not. If it is, but there is no sq_item method, then PySequence_GetItem gives the does not support indexing

Re: [Python-Dev] (try-except) conditional expression similar to (if-else) conditional (PEP 308)

On option 1 is this legal then? x = float(string) except float('nan') if some_check() else float('inf') if ValueError -Original Message- From: python-dev-bounces+dinov=microsoft@python.org [mailto:python-dev-bounces+dinov=microsoft@python.org] On Behalf Of Nick Coghlan Sent:

Re: [Python-Dev] (try-except) conditional expression similar to (if-else) conditional (PEP 308)

MRAB wrote: Dino Viehland wrote: On option 1 is this legal then? x = float(string) except float('nan') if some_check() else float('inf') if ValueError Well, is this is legal? try: x = float(string) except some_check(): x = float('nan') except

[Python-Dev] 2.6 object.__init__ deling __new__

I'm updating IronPython to match CPython's behavior w/ for this issue: http://bugs.python.org/issue1683368 One thing that I've noticed is that this doesn't seem to be respecting the deletion of attributes (on 2.6.2): class x(object): pass x().__init__(2,3,4) # throws - seems right class

Re: [Python-Dev] 2.6 object.__init__ deling __new__

Benjamin wrote: There's a wonderful comment about this in typeobject.c: This is basically the same what I've gathered from the issue description which was quite helpful. But in this case we're dealing with mutating the type object and changing whether __new__ or __init__ exist at all at

Re: [Python-Dev] [IronPython] Exception for setting attributes of built-in type

Seo wrote: Exception for setting attributes of built-in type differs between CPython and IronPython. This is not purely theoretical, as zope.interface tries to set Implements declaration as __implemented__ attribute of built-in type object, and excepts TypeError. Python 2.6.1 object.flag =

Re: [Python-Dev] [IronPython] Exception for setting attributes of built-in type

Guido wrote: I should add that this policy is also forced somewhat by the existence of the multiple interpreters in one address space feature, which is used e.g. by mod_python. This feature attempts to provide isolation between interpreters to the point that each one can have a completely

[Python-Dev] syntax warnings don't go through warnings.warn?

I'm just a little surprised by this - Is there a reason why syntax warnings are special and untrappable via warnings.warn? import warnings def mywarn(*args): print 'xx', args ... warnings.warn = mywarn compile(def f():\na = 1\nglobal a\n, , exec) :3: SyntaxWarning: name 'a' is

Re: [Python-Dev] syntax warnings don't go through warnings.warn?

PyErr_WarnEx? And warnings.catch_warnings doesn't work w/ parse warnings either so I'm not sure what the point of bringing that up is. -Original Message- From: Matthew Wilkes [mailto:matt...@matthewwilkes.co.uk] Sent: Monday, June 01, 2009 10:29 AM To: Dino Viehland Cc: Python-Dev Subject

Re: [Python-Dev] syntax warnings don't go through warnings.warn?

AM To: Michael Foord Cc: Dino Viehland; Python-Dev Subject: Re: [Python-Dev] syntax warnings don't go through warnings.warn? On 1 Jun 2009, at 18:42, Michael Foord wrote: Dino is developing Python - he's one of the core developers of IronPython Ah, sorry, I'm bad with names, don't always pick

Re: [Python-Dev] Indentation oddness...

other behavior right. I think I can safely ignore this one especially if it's just a bug. -Original Message- From: gvanros...@gmail.com [mailto:gvanros...@gmail.com] On Behalf Of Guido van Rossum Sent: Friday, May 29, 2009 7:20 PM To: Dino Viehland Cc: Robert Kern; python-dev@python.org

[Python-Dev] Indentation oddness...

Consider the code: code = def Foo():\n\npass\n\n This code is malformed in that the final indentation (2 spaces) does not agree with the previous indentation of the pass statement (4 spaces). Or maybe it's just fine if you take the blank lines should be ignored statement from the docs

[Python-Dev] Indentation oddness...

Consider the code: code = def Foo():\n\npass\n\n This code is malformed in that the final indentation (2 spaces) does not agree with the previous indentation of the pass statement (4 spaces). Or maybe it's just fine if you take the blank lines should be ignored statement from the docs

Re: [Python-Dev] Indentation oddness...

The 'single' mode, which is used for the REPL, is a bit different than 'exec', which is used for modules. This difference lets you insert blank lines of whitespace into a function definition without exiting the definition. Ending with a truly empty line does not cause the IndentationError,

Re: [Python-Dev] IronPython specific code in inspect module

Michael Foord wrote: I have IronPython specific versions of several of these functions which use .NET reflection and inspect could fallback to if sys.platform == 'cli'. Would it be ok for me to add these to the inspect module? Obviously the tests would only run on IronPython... The behaviour

Re: [Python-Dev] PEP 384: Defining a Stable ABI

Dirkjan Ochtman wrote: It would seem to me that optimizations are likely to require data structure changes, for exactly the kind of core data structures that you're talking about locking down. But that's just a high-level view, I might be wrong. In particular I would guess that ref

Re: [Python-Dev] Expression optimizations

And slightly unrelated, but just showing how bizarre floats are: x = 1e6 y = x/x cmp(y, y) 0 cmp(x/x, x/x) -1 Yeah object identity checks! From: python-dev-bounces+dinov=microsoft@python.org [mailto:python-dev-bounces+dinov=microsoft@python.org] On Behalf Of Daniel Stutzbach

Re: [Python-Dev] Expression optimizations

Mauro [mailto:cesare.dima...@a-tono.com] Sent: Tuesday, February 10, 2009 1:12 PM To: Dino Viehland Cc: Daniel Stutzbach; cesare.dima...@a-tono.com; Python-Dev Subject: RE: [Python-Dev] Expression optimizations It's bizarre enough, since I have got a different result (with Python 2.6.1, 32 bit): x

[Python-Dev] should list's call to __len__ swallow SystemExit?

We had a bug reported that effectively boils down to we’re not swallowing exceptions when list calls __len__ (http://www.codeplex.com/WorkItem/View.aspx?ProjectName=IronPythonWorkItemId=20598). We can obviously make the change to catch exceptions here in IronPython even if it seems like a bad

Re: [Python-Dev] Python-3.0, unicode, and os.environ

Does anyone know what Mono does here? Presumably they have the exact same problem as all strings in .NET are Unicode, and filenames/env vars/etc... are always strings. Maybe if it's gotta be broken at least it can be broken in a manner that's consistent with others :) -Original

Re: [Python-Dev] format specification mini-language docs...

: Tuesday, November 25, 2008 4:38 AM To: Dino Viehland Cc: python-dev@python.org dev Subject: Re: [Python-Dev] format specification mini-language docs... Dino Viehland wrote: previously discussed cases deleted Finally providing any sign character seems to cause +1.0#INF and friends

[Python-Dev] format specification mini-language docs...

Ok, now I'm implementing __format__ support for IronPython. The format spec mini-language docs say that a presentation type of None is the same as 'g' for floating point / decimal values. But these two formats seem to differ based upon how they handle whole numbers: 2.0.__format__('') '2.0'

[Python-Dev] bytearray methods returning self...

I've been implementing bytearray for IronPython and I noticed a couple of spots where the non-mutating methods of bytearray return self. In 2.6 but not in 3.0 RC2: x = bytearray(b'abc') y = x.replace(b'abc', b'bar', 0) id(x) == id(y) In 2.6 and in 3.0 RC2: t = bytearray() for i in range(256):

Re: [Python-Dev] bytearray methods returning self...

Sure, it's now bug 4348 - http://bugs.python.org/issue4348 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Guido van Rossum Sent: Tuesday, November 18, 2008 1:14 PM To: Dino Viehland Cc: python-dev@python.org dev Subject: Re: [Python-Dev] bytearray

Re: [Python-Dev] Reserving an arg space for Jython

IronPython already uses -X:OptionName for special IronPython only options so +1 for -X. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Frank Wierzbicki Sent: Friday, April 11, 2008 12:14 PM To: Brett Cannon Cc: Guido van Rossum; python-dev@python.org

Re: [Python-Dev] New lines, carriage returns, and Windows

This I don't understand. Why don't you just use binary mode then? At least for Python 2.x, the *only* difference between text and binary mode is the treatment of line endings. That just flips the problem to the other side. Now if I have a Python library that I'm mixing w/ .NET code I need to

Re: [Python-Dev] New lines, carriage returns, and Windows

can advice our users of the behavior when interoperating w/ APIs that return \r\n in strings. -Original Message- From: Martin v. Löwis [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 26, 2007 3:01 PM To: Dino Viehland Cc: python-dev@python.org Subject: Re: [Python-Dev] New lines

Re: [Python-Dev] [python] Re: New lines, carriage returns, and Windows

, September 26, 2007 3:15 PM To: Dino Viehland Cc: python-dev@python.org Subject: Re: [python] Re: [Python-Dev] New lines, carriage returns, and Windows Dino Viehland wrote: My understanding is that users can write code that uses only \n and Python will write the end-of-line character(s

Re: [Python-Dev] New Super PEP

Being able to access the calling frame from IronPython would be really useful... We do have a -X:Frames option but it's going to hurt your performance, but for example: IronPython 1.0.60816 on .NET 2.0.50727.312 Copyright (c) Microsoft Corporation. All rights reserved. def f(): ... x =

Re: [Python-Dev] New Super PEP

Just to chime in from the IronPython side (better late than never I suppose): If we need to get access to the frame which is calling super then we can make that happen in IronPython. It just means that super gets treated like we treat eval today and won't work if it's been aliased.

[Python-Dev] locals(), closures, and IronPython...

def a(): x = 4 y = 2 def b(): print y, locals() print locals() b() a() in CPython prints: {'y': 2, 'x': 4, 'b': function b at 0x020726F0} 2 {'y': 2} I'm wondering if it's intentional

Re: [Python-Dev] locals(), closures, and IronPython...

, developers and other implementation efforts (e.g. PyPy, Jython). On 3/5/07, Dino Viehland [EMAIL PROTECTED] wrote: def a(): x = 4 y = 2 def b(): print y, locals() print locals

[Python-Dev] .pyc file has different result for value 1.79769313486232e+308 than .py file

We've noticed a strange occurance on Python 2.4.3 w/ the floating point value 1.79769313486232e+308 and how it interacts w/ a .pyc. Given x.py: def foo(): print str(1.79769313486232e+308) print str(1.79769313486232e+308) == 1.#INF The 1st time you run this you get the correct

Re: [Python-Dev] .pyc file has different result for value 1.79769313486232e+308 than .py file

PROTECTED] Sent: Wednesday, September 13, 2006 11:39 AM To: Dino Viehland Cc: python-dev@python.org; Haibo Luo Subject: Re: [Python-Dev] .pyc file has different result for value 1.79769313486232e+308 than .py file [Dino Viehland] We've noticed a strange occurance on Python 2.4.3 w/ the floating

[Python-Dev] 2.4 2.5 beta 3 crash

We've been working on fixing some exception handling bugs in IronPython where we differ from CPython. Along the way we ran into this issue which causes CPython to crash when the code below is run. It crashes on both 2.4 and 2.5 beta 3. The code's technically illegal, but it probably

Re: [Python-Dev] 2.4 2.5 beta 3 crash

wrote: Dino Viehland [EMAIL PROTECTED] wrote: We've been working on fixing some exception handling bugs in IronPython where we differ from CPython. Along the way we ran into this issue which causes CPython to crash when the code below is run. It crashes on both 2.4 and 2.5 beta 3

Re: [Python-Dev] 2.4 2.5 beta 3 crash

:[EMAIL PROTECTED] Sent: Wednesday, August 16, 2006 10:11 AM To: Dino Viehland; python-dev@python.org Subject: Re: [Python-Dev] 2.4 2.5 beta 3 crash Dino Viehland [EMAIL PROTECTED] wrote: We've been working on fixing some exception handling bugs in IronPython where we differ from CPython. Along

Re: [Python-Dev] __getslice__ usage in sre_parse

I've also opened a bug for supporting __getslice__ in IronPython. Do you want to help develop Dynamic languages on CLR? (http://members.microsoft.com/careers/search/details.aspx?JobID=6D4754DE-11F0-45DF-8B78-DC1B43134038) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL

Re: [Python-Dev] [IronPython] [Mono-dev] IronPython Performance

On the recursion limits: Until beta 6 IronPython didn't have proper support for limiting recursion depth. There was some minor support there, but it wasn't right. In beta 6 we have full support for limiting recursion depth, but by default we allow infinite recursion. If the user explicitly

Re: [Python-Dev] [IronPython] base64 module

Well, CPython at least still enforces the padding, even if it's ignoring the invalid characters. Here's Seo's repro 'simplified' to go straight to binascii (just to get to the root API): import binascii binascii.a2b_base64('%') '' And then sending a valid character, invalid padding: