Re: [Python-Dev] Arbitrary non-identifier string keys when using **kwargs

[Jeff Hardy]

On Sun, Oct 14, 2018 at 12:15 PM Jeff Allen  wrote:
>
>
> On 10/10/2018 00:06, Steven D'Aprano wrote:
>
> On Tue, Oct 09, 2018 at 09:37:48AM -0700, Jeff Hardy wrote:
>
> ...
>
> From an alternative implementation point of view, CPython's behaviour
> *is* the spec. Practicality beats purity and all that.
>
> Are you speaking on behalf of all authors of alternate implementations,
> or even of some of them?
>
> It certainly is not true that CPython's behaviour "is" the spec. PyPy
> keeps a list of CPython behaviour they don't match, either because they
> choose not to for other reasons, or because they believe that the
> CPython behaviour is buggy. I daresay IronPython and Jython have
> similar.
>
> While agreeing with the principle, unless it is one of the fundamental 
> differences (GC, GIL), Jython usually lets practicality beat purity. When 
> faced with a certain combination of objects, one has to do something, and it 
> is least surprising to do what CPython does. It's also easier than keeping a 
> record.

This is how it is for IronPython as well. When the pool of potential
users is already small, one cannot afford to get too pedantic about
whether something is in the spec or not. Matching what CPython does is
the easiest way to make sure as many people as possible can use an
alternative implementation.

- Jeff
___
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] Arbitrary non-identifier string keys when using **kwargs

[Jeff Hardy]

On Sun, Oct 7, 2018 at 3:45 PM Terry Reedy  wrote:
>
> On 10/7/2018 1:34 PM, Chris Barker via Python-Dev wrote:
> > On Fri, Oct 5, 2018 at 3:01 PM Brett Cannon  > > wrote:
> >
> > I'm also fine with saying that keys in **kwargs that are not proper
> > identifiers is an implementation detail.
> >
> >
> > It's not just **kwargs -- you can also use arbitrary names with
> > setattr() / getattr() :
> >
> > In [6]: setattr(foo, "4 not an identifier", "this works")
> >
> > In [7]: getattr(foo, "4 not an identifier")
> > Out[7]: 'this works'
>
> When this behavior of set/getattr was discussed a decade or so ago,
> Guido said not to disable it, but I believe he said it should not be
> considered a language feature.  There are other situations where CPython
> is 'looser' than the spec.

>From an alternative implementation point of view, CPython's behaviour
*is* the spec. Practicality beats purity and all that.

- Jeff
___
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] Slow down...

[Jeff Hardy]

On Mon, May 7, 2018 at 10:21 AM, Glenn Linderman  wrote:
> On 5/7/2018 7:59 AM, Eric Snow wrote:
>
> On Sun, May 6, 2018 at 8:25 PM, Nick Coghlan  wrote:
>
> I'm inclined to agree that a Python 3.8 PEP in the spirit of the PEP 3003
> language moratorium could be a very good idea.
>
> Note that the PEP specifically applies to "syntax, semantics, and
> built-ins".  Here's the full abstract [1]:
>
> This PEP proposes a temporary moratorium (suspension) of all changes to
> the
> Python language syntax, semantics, and built-ins for a period of
> at least two
> years from the release of Python 3.1. In particular, the moratorium
> would
> include Python 3.2 (to be released 18-24 months after 3.1) but allow
> Python
> 3.3 (assuming it is not released prematurely) to once again include
> language
> changes.
>
> This suspension of features is designed to allow non-CPython
> implementations
> to "catch up" to the core implementation of the language, help ease
> adoption
> of Python 3.x, and provide a more stable base for the community.
>
> -eric
>
> Here's my "lightning" response to a "lightning talk" about a moratorium:
>
> So if other implementations didn't catch up during the last moratorium,
> either the moratorium then was lifted too soon, or the other implementations
> don't really want to catch up, or the thought that they should catch up was
> deemed less important than making forward progress with the language. Have
> any of those opinions changed?

Speaking as the maintainer of IronPython during the last moratorium:
while catching up was certainly desirable, there simply wasn't enough
person-power to do it any reasonable amount of time (I'm not sure any
implementation besides PyPy even has yield-from, let alone async).
Between fixing issues in 2.x branches, trying to implement 3.x
features, and dealing with underlying platform churn I don't think
even two years was ever realistic. Plus, every feature has to be
considered with how it works in Python and the other platform (like,
what sort of fun .NET interop can we do with type annotations?).

Another moratorium would probably have the same (lack of) effect.
Better, IMO, to just raise the bar on expensive features and let them
catch up naturally.

- Jeff
___
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 515: Underscores in Numeric Literals

[Jeff Hardy]

On Thu, Feb 11, 2016 at 10:15 AM, Andrew Barnert via Python-Dev <
python-dev@python.org> wrote:

> On Feb 11, 2016, at 09:39, Terry Reedy  wrote:
> >
> > If trailing _ is allowed, to simplify the implementation, I would like
> PEP 8, while on the subject, to say something like "While trailing _s on
> numbers are allowed, to simplify the implementation, they serve no purpose
> and are strongly discouraged".
>
> That's a good point: we need style rules for PEP 8.
>
> But I think everything that's just obviously pointless (like putting an
> underscore between every pair of digits, or sprinkling underscores all over
> a huge number to make ASCII art), or already handled by other guidelines
> (e.g., using a ton of underscores to "line up a table" is the same as using
> a ton of spaces, which is already discouraged) doesn't really need to be
> covered. And I think trailing underscores probably fall into that category.
>
> It might be simpler to write a "whitelist" than a "blacklist" of all the
> ugly things people might come up with, and then just give a bunch of
> examples instead of a bunch of rules. Something like this:
>
> While underscores can legally appear anywhere in the digit string, you
> should never use them for purposes other than visually separating
> meaningful digit groups like thousands, bytes, and the like.
>
> 123456_789012: ok (millions are groups, but thousands are more common,
> and 6-digit groups are readable, but on the edge)
> 123_456_789_012: better
> 123_456_789_012_: bad (trailing)
> 1_2_3_4_5_6: bad (too many)
> 1234_5678: ok if code is intended to deal with east-Asian numerals
> (where 1 is a standard grouping), bad otherwise
> 3__141_592_654: ok if this represents a fixed-point fraction
> (obviously bad otherwise)
> 123.456_789e123: good
> 123.456_789e1_23: bad (never useful in exponent)
> 0x1234_5678: good
> 0o123_456: good
> 0x123_456_789: bad (3 hex digits is usually not a meaningful group)
>
> The one case that seems contentious is "123_456_j". Honestly, I don't care
> which way that goes, and I'd be fine if the PEP left out any mention of it,
> but if people feel strongly one way or the other, the PEP could just give
> it as a good or a bad example and that would be enough to clarify the
> intention.
>

I imagine that for whatever "bad" grouping you can suggest, someone,
somewhere, has a legitimate reason to use it. Any rule more complex than
"Use underscores in numeric literals only when the improve clarity" is
unnecessarily prescriptive.

- Jeff
___
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

[Python-Dev] Python Mobile-sig

[Jeff Hardy]

There is now a Python SIG dedicated to running Python on mobile
devices. Sign up for the mobile-...@python.org mailing list and find
out more at [1].

The Mobile-SIG exists to improve the usability of Python on mobile
devices, as mobile platforms have their own unique requirements and
constraints.

There are two goals:
* To collaborate on porting CPython to mobile platforms and ensure
that other Python implementations (i.e. Jython, IronPython) present
much the same environment as CPython when running on mobile devices.
* To collaborate on the design of modules for mobile-centric features
such as cameras, GPS, accelerometers, and other sensors to ensure
cross-platform and cross-implementation compatibility.

The intent is to work on mobile-centric features in this group before
proposal to python-dev, similar to how the distutils-sig operates.

- Jeff

[1] https://www.python.org/community/sigs/current/mobile-sig/
___
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

[Python-Dev] IronPython 2.7.5 Released

[Jeff Hardy]

On behalf of the IronPython team, I'm very happy to announce the
release of IronPython 2.7.5[1]. Like all IronPython 2.7-series
releases, .NET 4 is required to install it. Installing this release
will replace any existing IronPython 2.7-series installation.
Assemblies for embedding are provided for .NET 3.5, .NET 4, .NET 4.5,
and Silverlight 5.

IronPython 2.7.5 is primarily a collection of bug fixes[2] which
smooths off many of the remaining rough edges. The complete list of
changes[3] is also available.

A major new feature is the inclusion of `ensurepip`, which will
install the `pip` package manager:

```
; -X:Frames is required when using pip
ipy.exe -X:Frames -m ensurepip

; Run from an Administrator console if using IronPython installer
ipy.exe -X:Frames -m pip install html5lib
```

**Note:** The assembly version of IronPython has changed to 2.7.5.0.
All previous 2.7 versions had the same version (2.7.0.40) which caused
issues when different versions were installed. Publisher policy files
are used to so that applications don't have to be recompiled, but
recompiling is strongly recommended.

A huge thanks goes out to Pawel Jasinski, who contributed most of the
changes in this release. Thanks is also due to Simon Opelt, Alex Earl,
Jeffrey Bester, yngipy hernan, Alexander Köplinger,Vincent Ducros, and
fdanny.

For Visual Studio integration, check out Python Tools for Visual
Studio[4] which has support for IronPython as well as CPython, and
many other fantastic features.

IronPython 2.7.5 is also available for embedding via NuGet. The main
package is IronPython, and the standard library is in
IronPython.StdLib.

- Jeff

[1] http://ironpython.codeplex.com/releases/view/169382
[2] http://bit.ly/ipy275fixed
[3] https://github.com/IronLanguages/main/compare/ipy-2.7.4...ipy-2.7.5
[4] http://pytools.codeplex.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

Re: [Python-Dev] 2.7 Windows installers (Was: death to 2.7; long live 2.7)

[Jeff Hardy]

On Sun, Apr 13, 2014 at 9:51 PM, Martin v. Löwis mar...@v.loewis.de wrote:
 As I just said: to get started, run the current build process. Without
 knowing WiX in detail, I'd still claim that msi.py is superiour in
 terms of expressiveness (i.e. it can better compute what files go into
 the MSI). I'm almost certain that you need a full programming language
 to actually perform the entire build; one alternative to msi.py would
 be to have a Python script generating the WiX configuration files.

FWIW, that's exactly what IronPython does - most of the files are
fixed, but there are scripts to generate inclusions for the stdlib.
WiX and MSBuild are pretty powerful combo, even if the excess of
stabby brackets makes *me* stabby after a while.

- Jeff
___
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-checkins] cpython (3.3): Add -b and -X options to python man page.

[Jeff Hardy]

On Sun, Jun 23, 2013 at 8:40 AM, Maciej Fijalkowski fij...@gmail.comwrote:

  +.BI \-X  option
  +Set implementation specific option.
 
 
  Should probably be Set the implementation-specific option.

 Is there anyone respecting this notation? (I know pypy does not, it
 uses --jit and stuff)

 IronPython does, for -X:Frames and a few others.

- Jeff
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PyPy, Jython, IronPython: Enum convenience function and pickleablity

[Jeff Hardy]

On Thu, May 2, 2013 at 1:18 PM, fwierzbi...@gmail.com
fwierzbi...@gmail.com wrote:
 On Thu, May 2, 2013 at 12:07 PM, Ethan Furman et...@stoneleaf.us wrote:
 In order for the Enum convenience function to be pickleable, we have this
 line of code in the metaclass:

 enum_class.__module__ = sys._getframe(1).f_globals['__name__']

 This works fine for Cpython, but what about the others?
 This should work for Jython, but I can't say I like it. I believe
 IronPython has a sort of speedup mode that disallows the use of
 _getframe, and I'd like to add this to Jython someday.

It's not just a speedup mode, it's the default. IronPython requires
frames to explicitly enabled because tracking them is about a 10%
performance hit (or so Dino told me once upon a time).

If you must use it, please copy the code block from namedtuple that
ignores it on IronPython.

- Jeff
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python Language Summit at PyCon: Agenda

[Jeff Hardy]

On Mon, Mar 4, 2013 at 4:39 PM, Michael Foord fuzzy...@voidspace.org.uk wrote:

 On 1 Mar 2013, at 18:38, Antoine Pitrou solip...@pitrou.net wrote:

 On Fri, 1 Mar 2013 09:32:23 -0500
 Barry Warsaw ba...@python.org wrote:

 On the other hand in some ways Jython is sort of like Python on a
 weird virtual OS that lets the real OS bleed through some. This may
 still need to be checked in that way (there's are still checks of if
 os.name == 'nt' right?)

 Yeah, but that all old code ;)

 Hmm, what do you mean? `os.name == 'nt'` is still the proper way to
 test that we're running on a Windows system (more accurately, over the
 Windows API).


 It has been used incorrectly in a few places in the Python standard library - 
 Windows support code that would work correctly on IronPython is skipped 
 because os.name is *not* 'nt' on IronPython.  That was the case in the past 
 anyway. It's quite some time since I've used IronPython now.

I think you misremembered - there's lots of code that uses
`sys.platform == 'win32'` to detect Windows, but sys.platform is 'cli'
for IronPython. I'm pretty sure `os.name has always been 'nt' (when
running on Windows), and if not, it definitely is now.

Jython sets os.name to 'java' (IIRC), so there isn't a uniform way to
detect Windows across all implementations.

- Jeff
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [compatibility-sig] do all VMs implement the ast module? (was: Re: AST optimizer implemented in Python)

[Jeff Hardy]

On Mon, Aug 13, 2012 at 12:06 PM, Brett Cannon br...@python.org wrote:
 Time to ask the other VMs what they are currently doing (the ast module came
 into existence in Python 2.6 so all the VMs should be answer the question
 since Jython is in alpha for 2.7 compatibility).

IronPython has an _ast implementation that matches 2.7 as close as
reasonably possible.

- Jeff
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [compatibility-sig] making sure importlib.machinery.SourceLoader doesn't throw an exception if bytecode is not supported by a VM

[Jeff Hardy]

 1) imp.cache_from_source is unimplemented, it's an AttributeError.

Same for IronPython.


 2) sys.dont_write_bytecode is always false, we don't respect that flag (we 
 really
   should IMO, but it's not a high priority for me, or anyone else apparently)

Always True for IronPython. You can change it, but it doesn't affect anything.

- Jeff
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [compatibility-sig] making sure importlib.machinery.SourceLoader doesn't throw an exception if bytecode is not supported by a VM

[Jeff Hardy]

On Tue, Jun 12, 2012 at 12:01 PM, Brett Cannon br...@python.org wrote:
 On Tue, Jun 12, 2012 at 2:28 PM, Eric Snow ericsnowcurren...@gmail.com
 wrote:

 On Tue, Jun 12, 2012 at 10:48 AM, Brett Cannon br...@python.org wrote:
  I should mention another option is to add sys.dont_read_bytecode (I
  think I
  have discussed this with Frank at some point).

 Or check for sys.implementation.cache_tag is None...


 Perfect! Will that work for Jython (Franke) and IronPython (Jeff)?

IronPython will probably never *write* pyc files, but it might *read*
them at some point -- as I understand cache_tag, we'd set it to
whatever version of CPython's pyc files we could read (that seems to
violate the spirit of sys.implementation). The combination of that and
sys.dont_write_bytecode should cover all of the states; I'll just lock
down sys.dont_write_bytecode so that changes are completely ignored.


 This does mean, though, that imp.cache_from_source() and
 imp.source_from_cache() might need to be updated to raise a reasonable
 exception when sys.implementation.cache_tag is set to None as I believe
 right now it will raise a TypeError because None isn't a str. But what to
 raise instead? TypeError? EnvironmentError?

NotImplementedError?

- Jeff
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] backporting stdlib 2.7.x from pypy to cpython

[Jeff Hardy]

On Mon, Jun 11, 2012 at 8:28 AM, Eric Snow ericsnowcurren...@gmail.com wrote:
 Nick's option 2 would be an improvement, but I imagine that option 3
 would have been the most effective by far.  Of course, the key thing
 is how closely the various implementors would follow the new list.
 Only they could say, though Frank Wierzbicki seemed positive about it.

This has come up a couple of times recently (discussions on PEP 421
and PEP 405), so I think it would be worth while. I don't have the
time to track all of the different proposals that are in flux; it
would be nice to know when they're done and just need a sanity check
to make sure everything will work for other implementations.

- Jeff
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] backporting stdlib 2.7.x from pypy to cpython

[Jeff Hardy]

On Fri, Jun 8, 2012 at 8:13 AM, Matti Picus matti.pi...@gmail.com wrote:

 The windows port of pypy makes special demands on stdlib, specifically that
 files are explicitly closed. There are some other minor issues, in order to
 merge all the changes necessary to get pypy windows up to speed, around 10
 modules or at  least their tests seem to need to be modified.
 I have been doing a bit of work on the stdlib shipped with pypy 1.9
 (version 2.7.2 unfortunately) to make it compliant. Assuming there is 
 interest,
 what would be the best path to get, for instance, a modified version of
 mailbox.py with its tests (test_mailbox.py and test_old_mailbox.py) backported
 to cpython?

These fixes would also be useful for IronPython and possibly Jython as
well. Unclosed files are probably the biggest set of failures when
running CPython's tests on IronPython (along with assuming that
sys.platform == 'win32' means Windows). Whether or not they get
backported to CPython, it might be worth finding a way to share the
2.7 stdlib between the alternative implementations (changes to 3.x
should go into CPython, obviously).

- Jeff
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] sys.implementation

[Jeff Hardy]

On Thu, May 10, 2012 at 3:39 PM, Steven D'Aprano st...@pearwood.info wrote:
 Aye. Add a rule that all implementation specific (i.e. not defined in
 the PEP) keys must be prefixed with an underscore and I'm sold.


 So now we're adding a new convention to single underscore names? Single
 underscore names are implementation-specific details that you shouldn't use
 or rely on, except in sys.implementation, where they are an optional part of
 the public interface.

I've always seen _names as less implementation details and more 'here
be dragons; tread carefully'. I don't think adding a different
convention really changes that at all.

The underscore ones would (mostly) be implementation-specific anyway.
_clr_version is something only IronPython is going to have, for
example. If more than one implementation has something it can be
promoted to a non-underscore name, but I think that will be rare. Some
of the suggested metadata (like vcs_revision and build date) could
actually be required right out of the gate, and cache_tag should be
optional.

- Jeff
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 407: New release cycle and introducing long-term support versions

[Jeff Hardy]

On Tue, Jan 17, 2012 at 3:50 PM, Ezio Melotti ezio.melo...@gmail.com wrote:
 * What is the effect on PyPy/Jython/IronPython?  Can they just skip the
 feature releases and focus on the LTS ones?

At least for IronPython it's unlikely we'd be able track the feature
releases. We're still trying to catch up as it is.

Honestly, I don't see the advantages of this. Are there really enough
new features planned that Python needs a full release more than every
18 months?

- Jeff
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Jeff Hardy]

On Tue, Jan 10, 2012 at 4:20 PM, Martin v. Löwis mar...@v.loewis.de wrote:
 Win 8 is practically a new OS target - the nt module may need to be
 replaced with a metro module to handle it well.

 No, it's not. Everything continues to work just fine on Windows 8,
 as long as we keep developing desktop apps.

 Only if Metro Apps are the target things may need to be replaced (but
 only very few changes are necessary to the nt module to make it compile).

Yeah, that's what I meant. I should have said WinRT is ... instead
of Win 8 is   If nt can be made to work, than that's even better
than I expected.

- Jeff
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Jeff Hardy]

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 is practically a new OS target - the nt module may need to be
replaced with a metro module to handle it well.

Accessing the WinRT APIs directly from Python will also require a set
of Python projections for the API, which should be straightforward to
generate from the WinRT metadata files. I know Dino Viehland did some
work on that; not sure if he can elaborate or not though.

Otherwise, IronPython would be the only option for writing Metro apps
in Python - not that I'd be *horribly* upset at that :). IronPython is
slowly growing Metro support, and it seems like most things will work,
but the .NET framework shields it from a lot of the WinRT guts.

- Jeff
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 3151 state

[Jeff Hardy]

On Mon, Oct 3, 2011 at 11:32 AM, Antoine Pitrou solip...@pitrou.net wrote:

 On Mon, 3 Oct 2011 19:56:04 +0200
 Antoine Pitrou solip...@pitrou.net wrote:
 
  Hello,
 
  I am back from holiday ;) and we haven't heard from other
  implementations whether there was any difficulty for them in
  implementing PEP 3151.

 Alex Gaynor and Jim Baker (thank you!) just told me on IRC that there
 shouldn't be any problem for their respective projects (PyPy and
 Jython, if I'm not totally confused).


I don't see any issues for IronPython either.

- Jeff
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Windows 8 support

[Jeff Hardy]

On Wed, Sep 14, 2011 at 4:38 AM, Neil Hodgson nyamaton...@gmail.com wrote:
 Austin Fernandes:

 Which versions of python will be compatible with windows8. I am using
 currently 2.7.2 version.

   Current releases of both Python 2.7 and Python 3.2 appear to run
 fine on the Windows 8 Developer Preview. You should download and
 install the preview to ensure that your own code is compatible.

Another question is whether Python can take advantage of WinRT (the
new UI framework). It should be possible, as the new APIs were
designed to be used from dynamic languages, but I haven't decided if
I'm crazy enough to try it.

- Jeff
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Draft PEP: Simplified Package Layout and Partitioning

[Jeff Hardy]

On Tue, Jul 19, 2011 at 8:58 PM, P.J. Eby p...@telecommunity.com wrote:
 The biggest likely exception to the above would be when a piece of
 code tries to check whether some package is installed by importing
 it.  If this is done *only* by importing a top-level module (i.e., not
 checking for a ``__version__`` or some other attribute), *and* there
 is a directory of the same name as the sought-for package on
 ``sys.path`` somewhere, *and* the package is not actually installed,
 then such code could *perhaps* be fooled into thinking a package is
 installed that really isn't.

This part worries me slightly. Imagine a program as such:

datagen.py
json/foo.js
json/bar.js

datagen.py uses the files in json/ to generate sample data for a
database. In datagen.py is the following code:

try:
import json
except ImportError:
import simplejson as json

Currently, this works just fine, but if will break (as I understand
it) under the PEP because the json directory will become a virtual
package and no ImportError will be raised. Is there a mitigation for
this in the PEP that I've missed?

 However, even in the rare case where all these conditions line up to
 happen at once, the failure is more likely to be annoying than
 damaging.  In most cases, after all, the code will simply fail a
 little later on, when it actually tries to DO something with the
 imported (but empty) module.  (And code that checks ``__version__``
 attributes or for the presence of some desired function, class, or
 module in the package will not see a false positive result in the
 first place.)

It may only be annoying, but it's still a breaking change, and a
subtle one at that. Checking __version__ is of course possible, but
it's never been necessary before, so it's unlikely there's much code
that does it. It also makes the fallback code significantly less neat.

- Jeff
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 397 (Python launcher for Windows) reference implementation

[Jeff Hardy]

On Thu, Jun 30, 2011 at 4:13 AM, Michael Foord
fuzzy...@voidspace.org.uk wrote:
 In the latest update Mark also addressed my main concern, making the
 launcher configurable so it can also be used by alternative implementations
 (particularly IronPython for Windows). I've copied Jeff Hardy and Dino
 (IronPython maintainers) in on this, in the hope that they might take a look
 at the latest version of the PEP too...

I skimmed it a while back but haven't had the time to give an in-depth
study. On the surface it seems fine, but the devil is in the
details...

- Jeff
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com