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

[Willem Broekema]

On Sat, Oct 10, 2009 at 1:29 AM, Christian Heimes  wrote:
> I'm proposing two new attributes in the sys module: sys.implementation
> and sys.userdirsuffix.

This seems like a good idea.

I'm not sure this idea will easily be accepted, but I'd like to see
the sys module eventually split up in two parts, so it is very obvious
to both implementers and users which system-specific features are
portable and which are not:

a) implementation details of the C implementation (subversion, _*,
dllhandle, dont_write_bytecode, settscdump, ..) in one module,

b) portable functionality (interpreter name and version etc,
builtin_module_names, copyright, excepthook, settrace, ..) in the
other

- Willem (CLPython)
___
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

[Python-Dev] Top-posting on this list

[Stephen J. Turnbull]

Brett Cannon writes:

 > On Fri, Oct 9, 2009 at 11:32, Michael Foord wrote:

 > > Sorry for top-posting, mobile device.

Michael, I for one *very much* appreciate your courtesy.

 > Aahz was the most adamant hater of top-posting and he isn't subscribed to
 > python-dev anymore, so whatever.

Please, let's encourage people to indicate if they top-post.  In the
modern environment bandwidth is not really a consideration, but I *do*
read to the bottom on lists like this one, where the *great* majority
of posters do a good job of trimming.

___
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] eggs now mandatory for pypi?

[M.-A. Lemburg]

"Martin v. Löwis" wrote:
>> I know that the issue tracker for PyPI is (still) on SF, but
>> development appear to happen elsewhere and I can't find any
>> contact information on the PyPI web pages.
> 
> PyPI discussion takes place mostly on catalog-sig.

Ok, then I'll sign up there.

Thanks,
-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Oct 10 2009)
>>> Python/Zope Consulting and Support ...http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/


::: Try our new mxODBC.Connect Python Database Interface for free ! 


   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
   Registered at Amtsgericht Duesseldorf: HRB 46611
   http://www.egenix.com/company/contact/
___
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 about sys.implementation and implementation specific user site directory

[M.-A. Lemburg]

Benjamin Peterson wrote:
> I forgot to ask before: Does this deprecate platform.python_implementation()?

No, platform.py is meant to be portable across multiple Python
versions and as such not really suitable for such deprecations.

It'll also take a long while before all Python implementations
expose a new sys module attribute along the proposed lines.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Oct 10 2009)
>>> Python/Zope Consulting and Support ...http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/


::: Try our new mxODBC.Connect Python Database Interface for free ! 


   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
   Registered at Amtsgericht Duesseldorf: HRB 46611
   http://www.egenix.com/company/contact/
___
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 about sys.implementation and impleme ntation specific user site directory

[Antoine Pitrou]

Willem Broekema  gmail.com> writes:
> 
> a) implementation details of the C implementation (subversion, _*,
> dllhandle, dont_write_bytecode, settscdump, ..) in one module,
> 
> b) portable functionality (interpreter name and version etc,
> builtin_module_names, copyright, excepthook, settrace, ..) in the
> other

Where does _getframe() end? :)

Regards

Antoine.


___
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 about sys.implementation and implementation specific user site directory

[Benjamin Peterson]

2009/10/10 Willem Broekema :
> On Sat, Oct 10, 2009 at 1:29 AM, Christian Heimes  wrote:
>> I'm proposing two new attributes in the sys module: sys.implementation
>> and sys.userdirsuffix.
>
> This seems like a good idea.
>
> I'm not sure this idea will easily be accepted, but I'd like to see
> the sys module eventually split up in two parts, so it is very obvious
> to both implementers and users which system-specific features are
> portable and which are not:

I'm afraid this has already been proposed and rejected. See
http://www.python.org/dev/peps/pep-3139/.



-- 
Regards,
Benjamin
___
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 about sys.implementation and implementation specific user site directory

[Nick Coghlan]

M.-A. Lemburg wrote:
> Benjamin Peterson wrote:
>> I forgot to ask before: Does this deprecate platform.python_implementation()?
> 
> No, platform.py is meant to be portable across multiple Python
> versions and as such not really suitable for such deprecations.
> 
> It'll also take a long while before all Python implementations
> expose a new sys module attribute along the proposed lines.

However, the function could be updated to take advantage of the new
sys.implementation attribute when it was available. If it didn't find
it, it would fallback to figuring out the way it does now.

Cheers,
Nick.


-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
---
___
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 about sys.implementation and implementation specific user site directory

[Nick Coghlan]

Martin v. Löwis wrote:
> Doing some bike-shedding: I'd like to not use "cpython" as the name of
> the python.org implementation. This term, I believe, was coined around
> JPython, somehow making the implementation language the primary means
> of distinction. However, there may be alternative implementations
> written in C (e.g. unladen swallow), or otherwise be "C based" (e.g.
> pypy).

However, CPython has been used for years to distinguish
CPython-the-reference-implementation from
Python-the-language-definition. Starting to call it something else now
would just confuse people for no good reason.

As Greg said, it may be better to think of it as standing for "Classic
Python" rather than merely "A Python interpreter written in C".

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
---
___
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 about sys.implementation and implementation specific user site directory

[Michael Foord]

Christian Heimes wrote:

Fellow Python developers!

In the light of our recent discussion about implementation specific
information and user site directory I like to start a new PEP. Much to
my regret I wasn't able to contribute to Python core development over
the past months. I hope I can find some free time over the next weeks.

Before I start with the PEP I like to reach consensus over the goal.
Alternative implementations of our beloved programming languages are
becoming more important every day. Although IronPython, Jython and PyPy
are trying hard to get as compatible to CPython as possible there are
numerous reasons for conditional code. General Python unit tests vs.
CPython specific unit tests are one reasons, implementation specific
module search paths are another. At the moment Python has no easy way to
inspect the implementation besides some code in the platform module.

I'm proposing two new attributes in the sys module: sys.implementation
and sys.userdirsuffix.
  


Why not just sys.implementation as a string? Everything else can 
trivially be deduced from that anyway. What is the use-case for the 
extra information?


Michael


sys.implementation
--

(Proposed by Nick, MAL and others.)

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 useful
for introspection and are already part of sys.version. I like to include
them for the sake of completeness.

id (required):
  lower case identifier, for example "cpython", "ironpython", "jython",
"pypy"

name (required):
  mixed case name of the implementation, for example "CPython",
"IronPython", "Jython", "PyPy"

platform (required):
  platform or language of the implementation, for example "C", ".NET",
"Java"

runtime (required):
  lower case runtime library of the implementation, for example "libc",
"msvcrt90", "java6", ".net"

compiler (required):
  verbose name of the compiler, for example "GCC 4.3.3", "Java
HotSpot(TM) Client VM (Apple Inc.)", "Mono JIT compiler version 2.0.1"

...


sys.userdirsuffix
-

sys.userdirsuffix is an implementation and platform specific string that
is used to construct the path for the user site directory as explained
in PEP 370. The string contains the implementation name as well as the
version number of Python.

Examples:
  python2.6 (CPython, Unix)
  Python26 (CPython, Windows)
  ironpython2.6 (IronPython, Unix)
  IronPython26 (IronPython, Windows)
  ...


Comments?

Christian

___
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/fuzzyman%40voidspace.org.uk
  



--
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog


___
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] transitioning from % to {} formatting

[Nick Coghlan]

Benjamin Peterson wrote:
> 2009/10/8 Eric Smith :
>> Christian Tanzer wrote:
>>> IMHO, either the translation is done once and gives identical output or
>>> it isn't worth doing at all.
>> I disagree. I doubt even 0.001% of all format strings involve octal
>> formatting. Is it really worth not providing a transition path if it can't
>> cover this case?
> 
> It's also really easy to just write 0{:o} like my translator does.

That works so long as the original format string doesn't specify either
a space padded field width or else a sign character. For those the extra
zero needs to be inserted after the leading characters but before the
number, so the formatting engine really has to handle it.

I'm actually thinking that having the ability to specify a single 0 as
the leading character for octal output is a legitimate feature. There
are plenty of other tools out there that use a single leading zero to
denote octal numbers (e.g. think of a Python script that generated C
code), so having Python be able to produce such numbers makes a lot of
sense.

Vinay's suggestion of using 'O' instead of 'o' to denote C-style octal
formatting instead of Python-style sounds reasonable to me (similar in
degree to the upper vs lower case distinction for 'x' and 'X' hex
formatting).

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
---
___
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] transitioning from % to {} formatting

[Nick Coghlan]

Glenn Linderman wrote:
> If you want to replace a C program that produces parsed output in a
> given format, and that given format includes leading-0-octal numbers,
> then it would be good to have the capability in Python .format, even
> though Python itself uses 0o prefix.
> 
> Similar arguments may apply anywhere else that sprintf produces
> something that .format cannot currently produce.

Heh, I should have read this before making my last comment - this is
exactly what I was trying to get at :)

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
---
___
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] transitioning from % to {} formatting

[Eric Smith]

Nick Coghlan wrote:

Benjamin Peterson wrote:

2009/10/8 Eric Smith :

Christian Tanzer wrote:

IMHO, either the translation is done once and gives identical output or
it isn't worth doing at all.

I disagree. I doubt even 0.001% of all format strings involve octal
formatting. Is it really worth not providing a transition path if it can't
cover this case?

It's also really easy to just write 0{:o} like my translator does.


That works so long as the original format string doesn't specify either
a space padded field width or else a sign character. For those the extra
zero needs to be inserted after the leading characters but before the
number, so the formatting engine really has to handle it.

I'm actually thinking that having the ability to specify a single 0 as
the leading character for octal output is a legitimate feature. There
are plenty of other tools out there that use a single leading zero to
denote octal numbers (e.g. think of a Python script that generated C
code), so having Python be able to produce such numbers makes a lot of
sense.

Vinay's suggestion of using 'O' instead of 'o' to denote C-style octal
formatting instead of Python-style sounds reasonable to me (similar in
degree to the upper vs lower case distinction for 'x' and 'X' hex
formatting).


Mark points out in http://bugs.python.org/issue7094 that we'd also need 
to add alternate float formatting for any automated translation facility 
to work flawlessly. There might be other float issues involving trailing 
decimals with no zeros that work differently, too.


Eric.
___
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 about sys.implementation and implementation specific user site directory

[Nick Coghlan]

Michael Foord wrote:
> Why not just sys.implementation as a string? Everything else can
> trivially be deduced from that anyway. What is the use-case for the
> extra information?

I think Christian's set of required attributes is much too large (I
would only have "name" as a required field), but I can understand the
desire to use a structure rather than a simple string.

As with sys.float_info, it gives a new namespace to store "info about
the implementation" without throwing more and more stuff into the main
sys namespace.

So it might start with just "name" being compulsory (since people can
use lower() to iron out any capitalisation issues), but allow
implementation specific attributes to migrate from the sys module to the
implementation namespace.

So "url" might become a common attribute, with each implementation
providing a pointer to their homepage. CPython might decide to put our
eventual Hg based replacement for sys.subversion under
sys.implementation instead of at the module level, etc.

A designated location for "put your implementation specific attributes
here" inside the sys module is a lot less hassle than creating a whole
new module for the purpose, but gives most of the same benefits.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
---
___
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 370 and IronPython

[Michael Foord]

Brett Cannon wrote:



On Fri, Oct 9, 2009 at 11:32, Michael Foord > wrote:


The *only* change in semantics I'm proposing is for users of
IronPython 2.6 which is not even at final release yet. CPython
users would be unaffected.


Then why can't IronPython patch site.py to do what they want? I still 
feel uncomfortable changing site.py for this in a micro release.


The IronPython team currently have legal issues distributing modified 
versions of the standard library (Dino can correct me if I'm wrong here).


That aside, I think that were a Python feature is implemented in such a 
way as to preclude compatibility with other implementations then we 
should see it as a bugfix to correct it.


I can't see why you should feel uncomfortable (beyond general 
principle), it seems clear that this change can't affect users of 
ClassicPython. It is not only IronPython that will benefit but also 
Jython when they port to Python 2.6.


As a general rule the alternative implementations will only start a 
serious port once a version is released and into maintenance mode. If we 
aren't able to fix compatibility issues then the implementations will 
always have to maintain their own patch sets that may or may not get 
merged back in (or in the case of implementations with awkward legal 
departments they'll have to ship bugs).


All the best,

Michael





On 9 Oct 2009, at 19:00, Brett Cannon mailto:br...@python.org>> wrote:




On Fri, Oct 9, 2009 at 04:53, Michael Foord
mailto:fuzzy...@voidspace.org.uk>> wrote:

Christian Heimes wrote:

Michael Foord wrote:
 


I really like this scheme. The important thing for
IronPython is that we can get it into Python 2.6
(along with other fixes to make distutils compatible
with IronPython - like not attempting to
bytecode-compile when sys.dont_write_bytecode is True).
   



I don't think my proposal will land into 2.6. The changes
are too severe
for a bug fix release.
 



Right, certainly not adding umpteen new sys attributes. :-)

The problem is that the alternative implementations run well
behind Python-trunk, indeed it doesn't really make sense for
them to put a lot of effort into implementing a version that
is still in development. The result is that they discover
incompatibilites after a version has gone into 'bugfix only'
mode.

Whilst the fix you have described (add information to sys
that is used by site.py and distutils) is ideal it can only
go into 2.7. I would *still* like to see a fix in 2.6 - even
if it is simple logic in site.py using sys.platform (if
sys.platform == 'cli'; elif sys.platform == 'java' etc). That
way IronPython 2.6 is able to be compatible with Python 2.6.
This logic might need duplicating in distutils (I haven't
looked at how distutils works out where the user
site-packages folder is), but it is a 'maintenance only' fix.


But it's still a change in semantics. Tossing this into 2.6 would
mean that anyone who has worked around the current behaviour is
going to have a busted install.

-Brett 






--
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog


___
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

[Python-Dev] Initialization of __builtins__

[Vinay Sajip]

>I'm not top-posting, but gmane is giving me a hard time :-(

In the py3k branch, logging has the line

_unicode = 'unicode' in dir(__builtins__)

to determine the existence of Unicode support. The code in trunk, being 1.5.2
compatible, used

hasattr(types, 'UnicodeType')

I wanted to eliminate the types import and modernise the trunk code a bit, so I
copied the py3k line to the trunk version of logging. It didn't work as
expected! So I added the line

print dir(__builtins__)

in logging fairly early on (though not the very first line - just after the

__date__ = ...

line. Here's what I got with 2.7a0 and 2.6.1:

Python 2.7a0 (trunk:75292M, Oct  9 2009, 09:21:05) [MSC v.1500 32 bit (Intel)]
on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import logging
['__class__', '__cmp__', '__contains__', '__delattr__', '__delitem__',
 '__doc__', '__eq__', '__format__', '__ge__', '__getattribute__',
 '__getitem__', '__gt__', '__hash__', '__init__', '__iter__', '__le__',
 '__len__', '__lt__', '__ne__', '__new__', '__reduce__', '__reduce_ex__',
 '__repr__', '__setattr__', '__setitem__', '__sizeof__', '__str__',
 '__subclasshook__', 'clear', 'copy', 'fromkeys', 'get', 'has_key', 'items',
 'iteritems', 'iterkeys', 'itervalues', 'keys', 'pop', 'popitem',
 'setdefault', 'update', 'values']
>>>

ActivePython 2.6.1.1 (ActiveState Software Inc.) based on
Python 2.6.1 (r261:67515, Dec  5 2008, 13:58:38) [MSC v.1500 32 bit (Intel)]
on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import logging
['__class__', '__cmp__', '__contains__', '__delattr__', '__delitem__',
 '__doc__', '__eq__', '__format__', '__ge__', '__getattribute__',
 '__getitem__', '__gt__', '__hash__', '__init__', '__iter__', '__le__',
 '__len__', '__lt__', '__ne__', '__new__', '__reduce__', '__reduce_ex__',
 '__repr__', '__setattr__', '__setitem__', '__sizeof__', '__str__',
 '__subclasshook__', 'clear', 'copy', 'fromkeys', 'get', 'has_key', 'items',
 'iteritems', 'iterkeys', 'itervalues', 'keys', 'pop', 'popitem',
 'setdefault', 'update', 'values']
>>>

However, if I just do 

dir(__builtins__)

in the interactive prompt, I get the whole shebang.

Excuse my ignorance, but how come?

Regards,

Vinay Sajip

___
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] Initialization of __builtins__

[Benjamin Peterson]

2009/10/10 Vinay Sajip :
> Excuse my ignorance, but how come?

Because __builtins__ is a module in __main__ and a dict in other
places. You should always check __builtin__; __builtins__ is an
implementation detail.


-- 
Regards,
Benjamin
___
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] Initialization of __builtins__

[Antoine Pitrou]

Vinay Sajip  yahoo.co.uk> writes:
> 
> In the py3k branch, logging has the line
> 
> _unicode = 'unicode' in dir(__builtins__)

Why do you do this?
In py3k, unicode is always enabled but it's called "str" and the name "unicode"
doesn't exist.

> to determine the existence of Unicode support. The code in trunk, being 1.5.2
> compatible, used
> 
> hasattr(types, 'UnicodeType')

Why don't you simply write:

unicode_support = True
try:
unicode
except NameError:
unicode_support = False

?


___
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] Initialization of __builtins__

[Vinay Sajip]

Antoine Pitrou  pitrou.net> writes:

> Why do you do this?
> In py3k, unicode is always enabled but it's called "str" and the name 
> "unicode"
> doesn't exist.
> 

That wasn't done by me but by GvR (according to svn annotate) in r55818,
presumably during the stdlib porting to py3k. I just copied the line over, not
thinking it wouldn't work for 2.7.

> Why don't you simply write:
> 
> unicode_support = True
> try:
> unicode
> except NameError:
> unicode_support = False
> 

That's just about what I've actually done: I was just curious about the
difference between py3k and trunk :-)

If __builtins__ is an implementation detail which can't be relied on, should the
py3k code be changed to the try: form? Or shall I just remove the checks
altogether, since Unicode should always be there in 3.x?

Regards,

Vinay Sajip

___
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] Initialization of __builtins__

[Eric Smith]

Vinay Sajip wrote:

If __builtins__ is an implementation detail which can't be relied on, should the
py3k code be changed to the try: form? Or shall I just remove the checks
altogether, since Unicode should always be there in 3.x?


Remember that the identifier "unicode" isn't present in py3k. There it's 
"str" and it holds Unicode strings.


Unless you're trying to keep the code identical in both branches, I'd 
just remove the check in py3k and assume str is what you always want to use.


Eric.


___
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 370 and IronPython

[Dino Viehland]

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 want to ship a 
modified version of the standard library because it seems like it should
be standard.  It's also a little more convenient for us to not have to 
maintain a separate copy (although we do already do that for the tests).


___
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 370 and IronPython

[Brett Cannon]

On Sat, Oct 10, 2009 at 10:31, Michael Foord wrote:

> Brett Cannon wrote:
>
>>
>>
>> On Fri, Oct 9, 2009 at 11:32, Michael Foord 
>> > fuzzy...@voidspace.org.uk>> wrote:
>>
>>The *only* change in semantics I'm proposing is for users of
>>IronPython 2.6 which is not even at final release yet. CPython
>>users would be unaffected.
>>
>>
>> Then why can't IronPython patch site.py to do what they want? I still feel
>> uncomfortable changing site.py for this in a micro release.
>>
>
> The IronPython team currently have legal issues distributing modified
> versions of the standard library (Dino can correct me if I'm wrong here).
>
> That aside, I think that were a Python feature is implemented in such a way
> as to preclude compatibility with other implementations then we should see
> it as a bugfix to correct it.
>
> I can't see why you should feel uncomfortable (beyond general principle),
> it seems clear that this change can't affect users of ClassicPython. It is
> not only IronPython that will benefit but also Jython when they port to
> Python 2.6.
>

It's just principle. I'm not going to fight this as no one else has spoken
up with my view and both Dino and Frank would like this to happen.

The one unfortunate thing about this proposal is how this is going to mean I
have to install a package potentially four times if I want it available to
all possible Python interpreters. Then again, the chances of anyone beyond
the people on this mailing list using more than a single interpreter
regularly is so small that bothering to add support for yet another user
directory that works on any Python interpreter will not be worth it.

-Brett




> As a general rule the alternative implementations will only start a serious
> port once a version is released and into maintenance mode. If we aren't able
> to fix compatibility issues then the implementations will always have to
> maintain their own patch sets that may or may not get merged back in (or in
> the case of implementations with awkward legal departments they'll have to
> ship bugs).
>
> All the best,
>
> Michael
>
>
>
>
>>On 9 Oct 2009, at 19:00, Brett Cannon >> wrote:
>>
>>
>>>
>>>On Fri, Oct 9, 2009 at 04:53, Michael Foord
>>>mailto:fuzzy...@voidspace.org.uk>> wrote:
>>>
>>>Christian Heimes wrote:
>>>
>>>Michael Foord wrote:
>>>
>>>I really like this scheme. The important thing for
>>>IronPython is that we can get it into Python 2.6
>>>(along with other fixes to make distutils compatible
>>>with IronPython - like not attempting to
>>>bytecode-compile when sys.dont_write_bytecode is True).
>>>
>>>
>>>I don't think my proposal will land into 2.6. The changes
>>>are too severe
>>>for a bug fix release.
>>>
>>>
>>>Right, certainly not adding umpteen new sys attributes. :-)
>>>
>>>The problem is that the alternative implementations run well
>>>behind Python-trunk, indeed it doesn't really make sense for
>>>them to put a lot of effort into implementing a version that
>>>is still in development. The result is that they discover
>>>incompatibilites after a version has gone into 'bugfix only'
>>>mode.
>>>
>>>Whilst the fix you have described (add information to sys
>>>that is used by site.py and distutils) is ideal it can only
>>>go into 2.7. I would *still* like to see a fix in 2.6 - even
>>>if it is simple logic in site.py using sys.platform (if
>>>sys.platform == 'cli'; elif sys.platform == 'java' etc). That
>>>way IronPython 2.6 is able to be compatible with Python 2.6.
>>>This logic might need duplicating in distutils (I haven't
>>>looked at how distutils works out where the user
>>>site-packages folder is), but it is a 'maintenance only' fix.
>>>
>>>
>>>But it's still a change in semantics. Tossing this into 2.6 would
>>>mean that anyone who has worked around the current behaviour is
>>>going to have a busted install.
>>>
>>>-Brett
>>>
>>
>>
>>
>
> --
> http://www.ironpythoninaction.com/
> http://www.voidspace.org.uk/blog
>
>
>
___
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 370 and IronPython

[Kevin Teague]

On Oct 10, 2009, at 2:17 PM, Brett Cannon wrote:


The one unfortunate thing about this proposal is how this is going  
to mean I have to install a package potentially four times if I want  
it available to all possible Python interpreters. Then again, the  
chances of anyone beyond the people on this mailing list using more  
than a single interpreter regularly is so small that bothering to  
add support for yet another user directory that works on any Python  
interpreter will not be worth it.





Yeah, I imagine that the use-case of wanting to re-use a shared set of  
packages between multiple interpreter implementations is relatively  
small. But if you did want to do so, you could just export the  
location for your (PYTHONIMPLEMENTATIONNAME)PATH to the location you  
want to re-use and off you go ...


___
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 370 and IronPython

[Michael Foord]

Brett Cannon wrote:



On Sat, Oct 10, 2009 at 10:31, Michael Foord 
mailto:fuzzy...@voidspace.org.uk>> wrote:


Brett Cannon wrote:



On Fri, Oct 9, 2009 at 11:32, Michael Foord
mailto:fuzzy...@voidspace.org.uk>
>> wrote:

   The *only* change in semantics I'm proposing is for users of
   IronPython 2.6 which is not even at final release yet. CPython
   users would be unaffected.


Then why can't IronPython patch site.py to do what they want?
I still feel uncomfortable changing site.py for this in a
micro release.


The IronPython team currently have legal issues distributing
modified versions of the standard library (Dino can correct me if
I'm wrong here).

That aside, I think that were a Python feature is implemented in
such a way as to preclude compatibility with other implementations
then we should see it as a bugfix to correct it.

I can't see why you should feel uncomfortable (beyond general
principle), it seems clear that this change can't affect users of
ClassicPython. It is not only IronPython that will benefit but
also Jython when they port to Python 2.6.


It's just principle. I'm not going to fight this as no one else has 
spoken up with my view and both Dino and Frank would like this to happen.


The one unfortunate thing about this proposal is how this is going to 
mean I have to install a package potentially four times if I want it 
available to all possible Python interpreters. Then again, the chances 
of anyone beyond the people on this mailing list using more than a 
single interpreter regularly is so small that bothering to add support 
for yet another user directory that works on any Python interpreter 
will not be worth it.




It is unfortunate, there are quite a few modules that I use with both 
IronPython and ClassicPython. Unfortunately there are many others where 
I have to make modifications or replace components (especially C 
extensions). It is these modules that require changes that mean separate 
site-packages directories are needed.


To be honest, at the moment I tend to bundle all third party 
dependencies in with my IronPython projects. As distutils support for 
IronPython improves I hope that will change.


All the best,


Michael


-Brett




As a general rule the alternative implementations will only start
a serious port once a version is released and into maintenance
mode. If we aren't able to fix compatibility issues then the
implementations will always have to maintain their own patch sets
that may or may not get merged back in (or in the case of
implementations with awkward legal departments they'll have to
ship bugs).

All the best,

Michael




   On 9 Oct 2009, at 19:00, Brett Cannon mailto:br...@python.org>
   >> wrote:



   On Fri, Oct 9, 2009 at 04:53, Michael Foord
   mailto:fuzzy...@voidspace.org.uk>
>> wrote:

   Christian Heimes wrote:

   Michael Foord wrote:
   
   I really like this scheme. The important

thing for
   IronPython is that we can get it into
Python 2.6
   (along with other fixes to make distutils
compatible
   with IronPython - like not attempting to
   bytecode-compile when
sys.dont_write_bytecode is True).
 


   I don't think my proposal will land into 2.6.
The changes
   are too severe
   for a bug fix release.
   


   Right, certainly not adding umpteen new sys
attributes. :-)

   The problem is that the alternative implementations
run well
   behind Python-trunk, indeed it doesn't really make
sense for
   them to put a lot of effort into implementing a
version that
   is still in development. The result is that they
discover
   incompatibilites after a version has gone into
'bugfix only'
   mode.

   Whilst the fix you have described (add information
to sys
   that is used by site.py and distutils) is ideal it
can only
   go into 2.7. I would *still* like to see a fix in
2.6 - even
   if it is simple logic in site.py using sys.platform (if
   sys.platform == 'cli'; elif sys.platform == 'java'
 

Re: [Python-Dev] Top-posting on this list

[Greg Ewing]

Stephen J. Turnbull wrote:

In the
modern environment bandwidth is not really a consideration,


That's no reason to squander it, though. Quoting the entire
message every time makes the size of the thread grow as
O(n**2), and makes things harder to read as well. That's
just senseless.

The only possible benefit is to allow latecomers to catch
up on the thread without having to consult any archives.
But I've never seen any complaints that people who *do*
quote responsibly are making this hard, so I can only
conclude that it's not a significant problem.

--
Greg
___
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] Top-posting on this list

[Stephen J. Turnbull]

Greg Ewing writes:

 > That's no reason to squander it, though. Quoting the entire
 > message every time makes the size of the thread grow as
 > O(n**2),

Agreed, but let's not exaggerate.  Threads are finite, so big O is not
really relevant.  Spam OTOH is boundless, and that's where the
bandwidth is going.

 > and makes things harder to read as well.

Indeed, and that's why I thanked Michael.  Trimming can be a PITA if
you're using a crummy MUA, and for reasons I have no intention of even
trying to remember, let alone understand, a lot of people are very
attached to their crummmy MUAs.  But adding a few words to at least
make it a little readable (whether apologetic or factual) would make
me a lot happier ... given that they're going to top post anyway.

___
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] Top-posting on this list

[Fred Drake]

On Sat, Oct 10, 2009 at 8:02 PM, Greg Ewing  wrote:
> That's no reason to squander it, though. Quoting the entire
> message every time makes the size of the thread grow as
> O(n**2), and makes things harder to read as well. That's
> just senseless.

Most importantly, insufficient trimming makes many of us start to
ignore threads we'd otherwise want to read more carefully or
participate in, because the tedium of wading through all the quotes to
make sure we catch all the content.


  -Fred

-- 
Fred L. Drake, Jr.
"Chaos is the score upon which reality is written." --Henry Miller
___
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