n fork:
https://github.com/facebookincubator/cinder
We started filing bpo issues for a few of the pieces we want to merge
upstream (links are in the google doc), and are looking forward to feedback
from the community on the issues, overall approach, or any feedback on the
features themselves.
Cheers
>
> The Instagram team behind the Cinder project may be interested to
> review Mark's work before it's merged into Python development branch.
> A design PEP would be more convenient than reviewing an concrete
> implementation.
I can't speak for others on the Cinder team, but I would definitely be
To potentially help provide a little bit of additional detail around our
approach I've spent some time writing up our internal details of the shadow
byte code implementation, and landed that in our Cinder repo here:
https://github.com/facebookincubator/cinder/blob/cinder/3.8/CinderDoc/shadowcode.rs
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 tri
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
>
> 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
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 sens
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) w
On Mon, Jun 20, 2016 at 12:59 PM, Brett Cannon
mailto:br...@python.org>> 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 similar to a trick used
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 wo
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
> features of C99.
>
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 t
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 -
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_FA
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 WINA
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 invo
January 08, 2012 10:13 PM
To: Antoine Pitrou
Cc: 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 wrote:
> Depending on the extent of removed/disabled functionality, it might
> not be very interesting
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
> poin
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 multiple-implemen
Guido wrote:
> On Mon, Apr 4, 2011 at 10:05 AM, 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 4, 2011 a
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 awe
Maciej wrote:
> On Sat, Apr 17, 2010 at 11:38 AM, Dino Viehland
> wrote:
> > Benjamin wrote:
> >> 2010/4/17 Guido van Rossum :
> >> > On Sat, Apr 17, 2010 at 9:22 AM, Nick Coghlan
> >> wrote:
> >> >> Guido van Rossum wrote:
> >&
Benjamin wrote:
> 2010/4/17 Guido van Rossum :
> > On Sat, Apr 17, 2010 at 9:22 AM, Nick Coghlan
> 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 implemented a
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 a
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
Antoine wrote:
> Dino Viehland 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. Ul
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 spe
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 con
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
> exp
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
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. I
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
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
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
Mark wrote:
> On Wed, Sep 23, 2009 at 4:54 PM, Dino Viehland 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
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 t
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" m
Frank wrote:
> > For IronPython we wrote a set of tests which go through and define
> > the various operator methods in all sorts of combinations on both
> > new-style and old-style classes as well as subclasses of those
> classes
> > and then do the comparisons w/ logging.
> We've talked about thi
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 "", line 1, in
TypeError: 'set' object does not support indexing
>>> class c(object): pass
...
>>> c()[2]
Traceba
Willem wrote:
>
> It's easy for other implementations to get this wrong. :)
For IronPython we wrote a set of tests which go through and define
the various operator methods in all sorts of combinations on both
new-style and old-style classes as well as subclasses of those classes
and then do the
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
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: Th
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 runt
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 x(obj
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
> >>> obje
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 completel
2009 10:49 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 ba
rser also go through 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 V
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: n
ing to get 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
> 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 Indentatio
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
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
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 behaviou
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 co
we're assigning
ids differently :)
-Original Message-
From: Cesare Di 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&#x
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
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=IronPython&WorkItemId=20598).
We can obviously make the change to catch exceptions here in IronPython even if
it seems like a bad
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 Message
PROTECTED]
Sent: 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:
> Finally providing any sign character seems to cause +1.0#INF and friends to
> be returned
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.
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] byte
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):
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
Sub
> 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 t
, 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) th
7;\r', '') is the way to go we 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: py
We ran into an interesting user-reported issue w/ IronPython and the way Python
writes to files and I thought I'd get python-dev's opinion.
When writing a string in text mode that contains \r\n we both write \r\r\n
because the default write mode is to replace \n with \r\n. This works great as
>>> 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():
...
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.
-Origin
in the method? Wouldn't you need a new opcode
which would resolve to a non-local variable or add it explicitly into the LEGB
search?
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jeremy Hylton
Sent: Tuesday, March 06, 2007 4:54 AM
To: Dino Viehlan
Thanks Guido. It might take some time (and someone may very well beat me to it
if they care a lot) but I'll see if we can get the PEP started.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Guido van Rossum
Sent: Monday, March 05, 2007 2:14 PM
To:
def a():
x = 4
y = 2
def b():
print y, locals()
print locals()
b()
a()
in CPython prints:
{'y': 2, 'x': 4, 'b': }
2 {'y': 2}
I'm wondering if it's intentional that these don't print d
Tim Peters [mailto:[EMAIL 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 strang
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
Carlson [mailto:[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
>
Yeah, continue inside the finally block is illegal. If you don't have the
extra try/except nesting then continue is detected as a syntax error.
-Original Message-
From: Dennis Allison [mailto:[EMAIL PROTECTED]
Sent: Wednesday, August 16, 2006 10:22 AM
To: Josiah Carlson
Cc:
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 shouldn't
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 PROTECTE
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 s
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:
>
81 matches
Mail list logo
