Re: [Python-Dev] Deprecation warnings in Python 2.7

[Nick Coghlan]

Antoine Pitrou wrote:
> Le Tue, 2 Mar 2010 17:28:11 -0800,
> Raymond Hettinger  a écrit :
>> -1 for several reasons.  
>>
>> 1) We've advertised -3 as part of TheOneTrueWay(tm).  It's a core
>> part of our transition story, so we should keep that as
>> clean/consistent as possible.  Deprecating the -3 switch seems like
>> shooting ourselves in the foot.
>>
>> 2) There is some chance that there will be a 2.8, so it isn't helpful
>> to burn down our bridges.
> 
> That's my feeling too. I think introducing a Py3kDeprecationWarning
> subclass is the right thing to do.

Agreed for the reasons Raymond cited. As far as the subclass goes, I
agree that's a good idea to allow people to readily detect whether they
tripped over a normal deprecation or a Py3 only deprecation when running
with -3 enabled.

As far as naming goes, I agree with Py3kDeprecationWarning since the
flag to enable them is called sys.py3kwarning.

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] Deprecation warnings in Python 2.7

[Florent Xicluna]

2010/3/3 Raymond Hettinger :
>
> -1 for several reasons.
> 1) We've advertised -3 as part of TheOneTrueWay(tm).  It's a core part of
> our transition story, so we should keep that as clean/consistent as
> possible.  Deprecating the -3 switch seems like shooting ourselves in the
> foot.

Instead of deprecating the -3 switch, we can change it to a useful
alias (see below).

> 2) There is some chance that there will be a 2.8, so it isn't helpful to
> burn down our bridges.
> ISTM, nothing is currently broken and in need of "fixing" in 2.7.
> I don't see any advantage to conflating py3k warnings with other
> deprecations.
>

IMHO, the current deprecation and warning mechanism is not far from a
Rube Goldberg machine.
There's many options available, and it's not obvious both for the core
developer and for the end user.

On the python interpreter side, you have many options for the careful developer:
 -Wdefault: display all warnings
 -3:display all warnings except ImportWarning and
PendingDeprecationWarning
 -Qwarn does nothing if -Wd is omitted, else warn about 2/1 or 2L/1
 -Qwarnall  does nothing if -Wd is omitted, else warn about 2.0/1 or 2j/1
 -b/-bb (undocumented), warns about u'' == bytearray('')
 -t/-tt warns about tab inconsistencies

Why -Qwarn needs -Wd to show its warnings?
And you should know that -3 implies -Qwarn, but it still mask
PendingDeprecationWarnings.
So you will not see the PendingDeprecationWarning issued by
cgi.parse_qs or shutil module (for example).

At the same time, you could notice that the mhlib module yields a
non-py3k DeprecationWarning about its removal in 3.0.

And now you want to compare unicode with bytes (ok, it's a very bad
idea, but it may happen when you sort dictionary keys, for example):

~ $ ./python

>>> u'\xff' == bytearray('\xff')# No warning?
False
>>> u'\xff' == '\xff'
__main__:1: UnicodeWarning: Unicode equal comparison failed to convert
both arguments to Unicode - interpreting them as being unequal
False

~ $ ./python -Wd -bb

>>> u'\xff' == bytearray('\xff')# It should raise an error because of '-bb'
__main__:1: BytesWarning: Comparison between bytearray and string
False
>>> u'\xff' == '\xff'
__main__:1: UnicodeWarning: Unicode equal comparison failed to convert
both arguments to Unicode - interpreting them as being unequal
False

Yeah, it may be confusing... "Comparison between bytearray and string"
is not really the correct message in 2.7. And why to keep these 2
warnings categories which are not used anywhere else in Python source
code?  The behavior should be consistent between these 2 warnings, and
they may share the same category. Why we don't use a RuntimeWarning
here?

I still support the simplification of the warnings mechanism:
 * -Qwarn/-Qwarnall should imply
-Wdefault -Wignore::ImportWarning -Wignore::PendingDeprecationWarning
(same as current -3 behavior)
 * BytesWarning should be replaced by UnicodeWarning or RuntimeWarning
(and -b deprecated)
 * -Wdefault should show all warnings (including py3k warnings)
 * -3 should show the PendingDeprecationWarning in addition to its
current behavior.
   (i.e. an alias for -Wdefault -Wignore::ImportWarning)

-- 
Florent
___
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 3188: Implementation Questions

[David Cournapeau]

On Fri, Feb 26, 2010 at 1:51 PM, Meador Inge  wrote:
> Hi All,
>
> Recently some discussion began in the issue 3132 thread
> (http://bugs.python.org/issue3132) regarding
> implementation of the new struct string syntax for PEP 3118.  Mark Dickinson
> suggested that I bring the discussion on over to Python Dev.  Below is a
> summary
> of the questions\comments from the thread.
>
> Unpacking a long-double
> ===
>
> 1. Should this return a Decimal object or a ctypes 'long double'?
> 2. Using ctypes 'long double' is easier to implement, but precision is
>     lost when needing to do arithmetic, since the value for cytpes 'long
> double'
>     is converted to a Python float.
> 3. Using Decimal keeps the desired precision, but the implementation would
>     be non-trivial and architecture specific (unless we just picked a
>     fixed number of bytes regardless of the architecture).
> 4. What representation should be used for standard size and alignment?
>     IEEE 754 extended double precision?

I think supporting even basic arithmetic correctly for long double
would be a tremendous amount of work in python. First, as you know,
there are many different formats which depend not only on the CPU but
also on the OS and the compiler, but there are quite a few issues
which are specific to long double (like converting to an integer which
cannot fit in any C integer type on most implementations).

Also, IEEE 754  does not define any alignment as far as I know, that's
up to the CPU implementer I believe. In Numpy, long double usually
maps to either 12 bytes (np.float96) or 16 bytes (np.float128).

I would expect the long double to be mostly useful for data exchange -
if you want to do arithmetic on long double, then the user of the
buffer protocol would have to implement it by himself (like NumPy does
ATM). So the important thing is to have enough information to use the
long double: alignment and size are not enough.

cheers,

David
___
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] Deprecation warnings in Python 2.7

[Florent Xicluna]

2010/3/3 Florent Xicluna :
>
 u'\xff' == bytearray('\xff')    # It should raise an error because of '-bb'
> __main__:1: BytesWarning: Comparison between bytearray and string
> False
 u'\xff' == '\xff'
> __main__:1: UnicodeWarning: Unicode equal comparison failed to convert
> both arguments to Unicode - interpreting them as being unequal
> False

I see that the BytesWarning (and -b option) is a 3.x feature.
I don't see the reason to keep it in 2.x, though

On the other side, UnicodeWarning is unused in 3.x, why we keep it
around? We may phase it out in 3.2?

-- 
Florent
___
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] code.python.org dead?

[Martin v. Löwis]

> It seems someone has decided that code.python.org doesn't resolve
> anymore.

I have now restored it.

Regards,
Martin
___
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] __file__

[Henning von Bargen]

Nick Coghlan wrote:

Another option is to remove bytecode-only support from the default
filesystem importer, but keep it for zipimport (since the stat call
savings don't apply in the latter case).


+1

Baptiste Carvello wrote:

However, making a difference between zipimport and the filesystem importer means 
the application will stop working if I unzip the library zip file, which is 
surprising.

> Unzipping the zip file can be handy when debugging a bug caused by a

forgotten module.


If the ZIP contains only bytecode files, it is just not intended
for changing any code, so I don't think this is an argument.
If you have access to the source code, you still can use that instead
of messing around with byte code.

Henning

___
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] Caching function pointers in type objects

[Daniel Stutzbach]

On Tue, Mar 2, 2010 at 9:06 PM, Reid Kleckner  wrote:

> I don't think this will help you solve your problem, but one thing
> we've done in unladen swallow is to hack PyType_Modified to invalidate
> our own descriptor caches.  We may eventually want to extend that into
> a callback interface, but it probably will never be considered an API
> that outside code should depend on.
>

Thanks Reid and Benjamin for the information.

I think I see a way to dramatically speed up PyObject_RichCompareBool when
comparing immutable, built-in, non-container objects (int, float, str,
etc.).  It would speed up list.sort when the key is one of those types, as
well as most operations on the ubiquitous dictionary with str keys.

Is that a worthwhile avenue to pursue, or is it likely to be redundant with
Unladen Swallow's optimizations?

If I can find time to pursue it, would it be best for me to implement it as
a patch to Unladen Swallow, CPython trunk, or CPython py3k?
--
Daniel Stutzbach, Ph.D.
President, Stutzbach Enterprises, LLC 
___
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] Caching function pointers in type objects

[Benjamin Peterson]

2010/3/3 Daniel Stutzbach :
> I think I see a way to dramatically speed up PyObject_RichCompareBool when
> comparing immutable, built-in, non-container objects (int, float, str,
> etc.).  It would speed up list.sort when the key is one of those types, as
> well as most operations on the ubiquitous dictionary with str keys.
>
> Is that a worthwhile avenue to pursue, or is it likely to be redundant with
> Unladen Swallow's optimizations?

Perhaps you could explain what exactly you want to do. :) That would
help us make a judgment.

>
> If I can find time to pursue it, would it be best for me to implement it as
> a patch to Unladen Swallow, CPython trunk, or CPython py3k?

Your choice.


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

[Python-Dev] Matching multiple regexes

[MRAB]

I've thought of a possible additional feature for my regex module and
I'm looking for opinions.

Occasionally there's a question about matching multiple regexes and
someone might suggest combining them into one regex using "|".

The feature would be to allow regex.compile, etc, to accept a list or
tuple of regex strings. These would be combined into a single regex
internally. The match object would get a new attribute .index which
would give the index of the regex string which matched.

An additional feature could be to allow regex.sub to accept as a
replacement any object which has the __getitem__ method and call that
method with the match index, if multiple regexes were used. (A
replacement string would still behave the same.)

This could mean that the following code would become possible:

>>> subs = [("foo", "bar"), ("baz", "quux"), ("quuux", "foo")]
>>> old_string, new_string = zip(*subs)
>>> s = "fooxxxbazyyyquuux"
>>> regex.sub(old_string, new_string, s)
"barxxxquuxyyyfoo"

___
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] Caching function pointers in type objects

[Daniel Stutzbach]

On Wed, Mar 3, 2010 at 3:29 PM, Benjamin Peterson wrote:

> 2010/3/3 Daniel Stutzbach :
> > I think I see a way to dramatically speed up PyObject_RichCompareBool
> when
> > comparing immutable, built-in, non-container objects (int, float, str,
> > etc.).  It would speed up list.sort when the key is one of those types,
> as
> > well as most operations on the ubiquitous dictionary with str keys.
>

(correcting myself)  I just noticed that CPython already optimizes
dictionaries with str-only keys and skips PyObject_RichCompareBool, so no
speed up there.  I think it would be redundant with optimization I have in
mind, so it could perhaps be taken out which would simplify the dict code a
bit and save a pointer in the dict structure.


> Perhaps you could explain what exactly you want to do. :) That would
> help us make a judgment.
>

It'd actually be a pretty small patch, so I think I should just explain it
by actually writing it. ;-)
--
Daniel Stutzbach, Ph.D.
President, Stutzbach Enterprises, LLC 
___
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] Release blocker: urllib2 issue 7540

[Fred Drake]

Regarding:  http://bugs.python.org/issue7540

The change made in response to this issue report breaks existing uses
of Python 2.6.4.

The mechanize library frequently re-initializes the data in the
request without re-using the request.  This worked fine in the past,
and does not trigger the problem reported without the request being
re-used.  Applications (including tests) that use mechanize now break
with this TypeError.  This includes much (if not all) of the Zope
community, which uses mechanize via zope.testbrowser.

The proper response to this issue for Python 2.6 is to make no code
changes (though a documentation enhancement may be in order).

This change should be reverted from all branches.

Python 2.6.5 should be blocked until this is done.


  -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

Re: [Python-Dev] [Pydotorg] FWD: Broken link in 2.6.5 rc 1 download page.

[Benjamin Peterson]

2010/3/3 Michael Foord 
>
> As far as I can tell there is no Python 2.6.5 documentation online and the 
> link to 3.1 docs is actually for 3.1.1 whilst the link for 3.1.1 docs is dead.

I've now fixed the 3.1.1 docs link.



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

[Python-Dev] FWD: Broken link in 2.6.5 rc 1 download page.

[Michael Foord]

As far as I can tell there is no Python 2.6.5 documentation online and 
the link to 3.1 docs is actually for 3.1.1 whilst the link for 3.1.1 
docs is dead.


The actual documentation doesn't seem to be in the pydotorg svn 
repository so I guess this a release manager issue?


Michael Foord

 Original Message 
Subject:[Pydotorg] FWD: Broken link in 2.6.5 rc 1 download page.
Date:   Wed, 3 Mar 2010 08:45:36 -0800
From:   Aahz 
Organization:   The Cat & Dragon
To: pydot...@python.org



- Forwarded message from Simon de Vlieger  -


 From: Simon de Vlieger
 To: webmas...@python.org
 Subject: Broken link in 2.6.5 rc 1 download page.
 Date: Wed, 3 Mar 2010 09:57:29 +0100

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 Dear webmaster (I know no name),

 on this page: http://www.python.org/download/releases/2.6.5/ both links
 for the documentation are incorrect. On this page:
 http://www.python.org/doc/versions/ the link for the Python 3.1.1 is
 broken.

 Hope to have informed you well enough.

 Regards,

 Simon de Vlieger
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.9 (Darwin)

 iQIcBAEBAgAGBQJLjiR5AAoJEBBSHP7i+JXfidsP/0fLCK0sn5+mj9CPsobDant7
 1tkXK7pwrbujXhpAyhjhE/kB5BhNI/h9XpmmUkLSZzz7AoOpE6KzlqCzOmwBmdAk
 6LxO2c4ZojICVB5zgNYXibDtnSwbBhcefbEsN6BSh1kI/3ThcIdWRYFavBAlxj1T
 6P7y8MOHUn3INLEw8foxV20geivcqzmMhRtfglMVs9KcB/PZWrK8fWw8K2Ov0B+U
 ihxaywfiJWcdkFKTTLNvQCbVr6ZGke728/7/lcWLvdPlwRPfVteKlLDglWX0beBy
 tgQyxmtxFx+AeCiLeyybnxEnxRVgU1nYxsdWluJuwFT4l+/BsJG3CkM522rQ3MWZ
 +DYB6xfONlvfCSXaPn3fOYesEvXek9BxKLiXpjWlJsmXvDcdFN2sr24aR1cJEXL8
 ZRkiJO5VFzngIxytk0Oy/SeMkxCUtsq4TMlMT2OyxblxxRoLikPSsfgKRuDkQ5s+
 QK2yNxTgKs2yA5ux9kmZscmVgHcWqJFjkE72dJoARyHMra9Jvcr2U7GVE2zqcOCS
 rObaqq61TpZmvlPUXlkLUueTUI9Djz01hAQUp+Vcwu8omVlIgZC0GbuXK8JDfQJd
 60WFI1BvUQg7mDB1ThUU6HUE9rF71921lx02YyZFzGFn1K2/w/bRhxrrzD5XwJDQ
 fFwYKj+pwgHO5AU5hMCR
 =rTPq
 -END PGP SIGNATURE-


- End forwarded message -

--
Aahz (a...@pythoncraft.com)<*>  http://www.pythoncraft.com/

"Many customs in this life persist because they ease friction and promote
productivity as a result of universal agreement, and whether they are
precisely the optimal choices is much less important." --Henry Spencer
___
Pydotorg mailing list
pydot...@python.org
http://mail.python.org/mailman/listinfo/pydotorg

___
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] Caching function pointers in type objects

[Collin Winter]

Hey Daniel,

On Wed, Mar 3, 2010 at 1:24 PM, Daniel Stutzbach
 wrote:
> On Tue, Mar 2, 2010 at 9:06 PM, Reid Kleckner  wrote:
>>
>> I don't think this will help you solve your problem, but one thing
>> we've done in unladen swallow is to hack PyType_Modified to invalidate
>> our own descriptor caches.  We may eventually want to extend that into
>> a callback interface, but it probably will never be considered an API
>> that outside code should depend on.
>
> Thanks Reid and Benjamin for the information.
>
> I think I see a way to dramatically speed up PyObject_RichCompareBool when
> comparing immutable, built-in, non-container objects (int, float, str,
> etc.).  It would speed up list.sort when the key is one of those types, as
> well as most operations on the ubiquitous dictionary with str keys.

That definitely sounds worth pursuing.

> Is that a worthwhile avenue to pursue, or is it likely to be redundant with
> Unladen Swallow's optimizations?

I don't believe it will be redundant with the optimizations in Unladen Swallow.

> If I can find time to pursue it, would it be best for me to implement it as
> a patch to Unladen Swallow, CPython trunk, or CPython py3k?

I would recommend patching py3k, with a backport to trunk.

Thanks,
Collin Winter
___
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] Caching function pointers in type objects

[Daniel Stutzbach]

On Wed, Mar 3, 2010 at 4:34 PM, Collin Winter wrote:

> I would recommend patching py3k, with a backport to trunk.
>

After thinking it over, I'm inclined to patch trunk, so I can run the
Unladen Swallow macro-benchmarks, then forward-port to py3k.

I'm correct in understanding that it will be a while before the Unladen
Swallow benchmarks can support Python 3, right?
--
Daniel Stutzbach, Ph.D.
President, Stutzbach Enterprises, LLC 
___
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] Caching function pointers in type objects

[Collin Winter]

On Wed, Mar 3, 2010 at 2:41 PM, Daniel Stutzbach
 wrote:
> On Wed, Mar 3, 2010 at 4:34 PM, Collin Winter 
> wrote:
>>
>> I would recommend patching py3k, with a backport to trunk.
>
> After thinking it over, I'm inclined to patch trunk, so I can run the
> Unladen Swallow macro-benchmarks, then forward-port to py3k.
>
> I'm correct in understanding that it will be a while before the Unladen
> Swallow benchmarks can support Python 3, right?

That's correct; porting the full benchmark suite to Python 3 will
require projects like Django to support Python 3.

Collin Winter
___
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] __file__

[Barry Warsaw]

On Mar 02, 2010, at 09:06 PM, Steven D'Aprano wrote:

>(1) What happens if the __cache__ directory doesn't exist and the 
>enclosing directory is unwriteable, or if it does exist, but is 
>unreadable?
>
>I expect that the byte code files will simply not be created, and 
>everything will continue without them.

s/__cache__/__pycache__

but yes, just as it does today.

>(2) Presumably this only effects imports, not running python source code 
>as a script. If I do this:
>
>python myscript.py
>
>from the shell, I would expect that no __cache__ directory will be 
>created, just like today. 

Correct.

-Barry


signature.asc
Description: PGP signature
___
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] The fate of Distutils in Python 2.7

[Tarek Ziadé]

Just FYI : I am post-poning the revert of Distutils to 2.6.x right
after 2.7a4 has been tagged to avoid any problems (this is in 3 days)

The revert is ready but 3 days is not long enough to make sure
everything is going smooth.

On Fri, Feb 26, 2010 at 10:44 PM, Tarek Ziadé  wrote:
> Hello,
>
> This is a follow-up of the Pycon summit + sprints on packaging.
>
> This is what we have planned to do:
>
> 1. refactor distutils in a new standalone version called distutils2
> [this is done already and we are actively working in the code]
> 2. completely revert distutils in Lib/ and Doc/ so the code + doc is
> the same than the current 2.6.x branch
> 3. leave the new sysconfig module, that is used by the Makefile and
> the site module
>
> The rest of the work will happen in distutils2 and we will try to
> release a version asap for Python 2.x and 3.x (2.4 to 3.2), and the
> goal
> is to put it back in the stdlib in Python 3.3
>
> Distutils in Python will be feature-frozen and I will only do bug
> fixes there.  All feature requests will be redirected to Distutils2.
>
> I think the easiest way to manage this for me and for the feedback of
> the community is to add in bugs.python.org a "Distutils2" component,
> so I can
> start to reorganize the issues in there and reassign new issues to
> Distutils2 when it applies.
>
> Regards
> Tarek
>
> --
> Tarek Ziadé | http://ziade.org
>



-- 
Tarek Ziadé | http://ziade.org
___
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] __file__ and bytecode-only

[Jim Jewett]

I understand the need to ship without source -- but why does that
require supporting .pyc (or .pyo) -only?

Couldn't vendors just replace the real .py files with empty files?

Then no one would need the extra stat call, and no one would be bitten
by orphaned .pyc files after a rename.

[Yes, zips could still allow unmatched names; yes, it would be helpful
if a tool were available to sync the last-modification time; yes a
deprecation release should still be needed.]

-jJ
___
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] code.python.org dead?

[Antoine Pitrou]

Le Wed, 03 Mar 2010 20:43:58 +0100,
"Martin v. Löwis"  a écrit :

> > It seems someone has decided that code.python.org doesn't resolve
> > anymore.
> 
> I have now restored it.

Thanks a lot!

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] __file__ and bytecode-only

[Barry Warsaw]

On Mar 03, 2010, at 07:37 PM, Jim Jewett wrote:

>I understand the need to ship without source -- but why does that
>require supporting .pyc (or .pyo) -only?
>
>Couldn't vendors just replace the real .py files with empty files?

Yes, I think that's a possibility.  What would people think about that?

-Barry


signature.asc
Description: PGP signature
___
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] __file__ and bytecode-only

[Brett Cannon]

On Wed, Mar 3, 2010 at 16:37, Jim Jewett  wrote:

> I understand the need to ship without source -- but why does that
> require supporting .pyc (or .pyo) -only?
>
> Couldn't vendors just replace the real .py files with empty files?
>

Because if someone screws up the mod time on the source files the .pyc files
will get recreated silently.

-Brett




>
> Then no one would need the extra stat call, and no one would be bitten
> by orphaned .pyc files after a rename.
>
> [Yes, zips could still allow unmatched names; yes, it would be helpful
> if a tool were available to sync the last-modification time; yes a
> deprecation release should still be needed.]
>
> -jJ
> ___
> 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/brett%40python.org
>
___
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] __file__ and bytecode-only

[Glenn Linderman]

On approximately 3/3/2010 5:49 PM, came the following characters from 
the keyboard of Barry Warsaw:

On Mar 03, 2010, at 07:37 PM, Jim Jewett wrote:
   

>I understand the need to ship without source -- but why does that
>require supporting .pyc (or .pyo) -only?
>
>Couldn't vendors just replace the real .py files with empty files?
 

Yes, I think that's a possibility.  What would people think about that?

-Barry
   


That's kooky, but not as kooky as my idea.  As mentioned elsewhere, 
timestamps would have to be treated carefully.


In this scenario, the .pyc files would still live in __pycache__ ?  
Complete with the foo..pyc naming ?


So one could actually create a "fat .zip" application that could work 
with a variety of installed Python versions ???  Hmm...


--
Glenn -- http://nevcal.com/
===
A protocol is complete when there is nothing left to remove.
-- Stuart Cheshire, Apple Computer, regarding Zero Configuration Networking

___
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] __file__ and bytecode-only

[Greg Ewing]

Barry Warsaw wrote:

On Mar 03, 2010, at 07:37 PM, Jim Jewett wrote:


Couldn't vendors just replace the real .py files with empty files?


Yes, I think that's a possibility.  What would people think about that?


Seems like a perverse thing to have to do to me.

Also a bit fragile, since you would have to make
sure that the empty .py files were dated older
than the .pyc files and stayed that way, lest
Python try to recompile them and wipe out your
code.

You would also have to be careful to build
installers that didn't recompile .py files on
installation. (Haven't had much experience building
installers using distutils, so I'm not sure
how much of a problem that would be.)

--
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] __file__ and bytecode-only

[Greg Ewing]

Glenn Linderman wrote:

In this scenario, the .pyc files would still live in __pycache__ ?  
Complete with the foo..pyc naming ?


It might be neater to have a separate cache directory
for each bytecode version, named __cache.__ or
some such.

--
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] __file__ and bytecode-only

[Glyph Lefkowitz]

On Mar 3, 2010, at 10:22 PM, Greg Ewing wrote:

> Glenn Linderman wrote:
> 
>> In this scenario, the .pyc files would still live in __pycache__ ?  Complete 
>> with the foo..pyc naming ?
> 
> It might be neater to have a separate cache directory
> for each bytecode version, named __cache.__ or
> some such.

Okay, this is probably some pretty silly bikeshedding, but: if we're going to 
have it be something.something-else, can we please make sure that 
.something-else is a common extension that means "python bytecode cache"?  It 
would be good to keep the file-manager and shell operations required to say 
"blow away bytecode cache directories" as simple as possible.

___
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] __file__ and bytecode-only

[Antoine Pitrou]

Le Wed, 3 Mar 2010 17:51:04 -0800,
Brett Cannon  a écrit :
> On Wed, Mar 3, 2010 at 16:37, Jim Jewett  wrote:
> 
> > I understand the need to ship without source -- but why does that
> > require supporting .pyc (or .pyo) -only?
> >
> > Couldn't vendors just replace the real .py files with empty files?
> >
> 
> Because if someone screws up the mod time on the source files
> the .pyc files will get recreated silently.

Unless the .py files arrange to raise a syntax error on compiling.



___
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] __file__ and bytecode-only

[Antoine Pitrou]

Le Thu, 04 Mar 2010 16:22:13 +1300,
Greg Ewing  a écrit :

> Glenn Linderman wrote:
> 
> > In this scenario, the .pyc files would still live in __pycache__ ?  
> > Complete with the foo..pyc naming ?
> 
> It might be neater to have a separate cache directory
> for each bytecode version, named __cache.__ or
> some such.
> 

Actually, I find it neater to have a single cache directory. It makes
for much less clutter, and simpler ignore rules.


___
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] __file__ and bytecode-only

[Greg Ewing]

Glyph Lefkowitz wrote:
if we're going to have it be something.something-else, can we please 
make sure that .something-else is a common extension that means 
"python bytecode cache"?


Maybe something like

  __bytecode-__.pycache

?

--
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] __file__ and bytecode-only

[Greg Ewing]

Antoine Pitrou wrote:


Unless the .py files arrange to raise a syntax error on compiling.


I guess that prevents a total disaster, but the
program is still broken and you have to hunt down
the offending files and fix the timestamps -- if
it's even evident what the problem is and how to
fix it.

--
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] __file__ and bytecode-only

[Greg Ewing]

Antoine Pitrou wrote:


Actually, I find it neater to have a single cache directory. It makes
for much less clutter, and simpler ignore rules.


Another possibility would be to have a single top-level
cache directory with a subdirectory for each version:

  __bytecode__.pycache//.pyc

I don't think this ought to increase the stat call
count, since the interpreter will always be looking
for a particular version of bytecode, so it can
just stat for the appropriate subdirectory
directly.

--
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] __file__ and bytecode-only

[Antoine Pitrou]

Le Thu, 04 Mar 2010 16:39:03 +1300,
Greg Ewing  a écrit :
> Antoine Pitrou wrote:
> 
> > Unless the .py files arrange to raise a syntax error on compiling.
> 
> I guess that prevents a total disaster, but the
> program is still broken and you have to hunt down
> the offending files and fix the timestamps -- if
> it's even evident what the problem is and how to
> fix it.
> 

Bytecode-only distributions are supposed to be created by the
vendor/distributor. It's up to him/her to get things right.

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] Release blocker: urllib2 issue 7540

[Senthil Kumaran]

On Thu, Mar 4, 2010 at 3:45 AM, Fred Drake  wrote:
> Regarding:  http://bugs.python.org/issue7540
>
> The proper response to this issue for Python 2.6 is to make no code
> changes (though a documentation enhancement may be in order).
>
> This change should be reverted from all branches.
>
> Python 2.6.5 should be blocked until this is done.

I have commented on that issue.
Ready to revert the change from the branches and keep a doc fix and a warning.




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