Re: [Python-Dev] Traceback object has no __class__?

[Greg Ewing]

Nick Coghlan wrote:

I'm not sure what build you're getting that behaviour on, but my svn
build of 2.6 has a __class__ attribute for traceback objects,


It's 2.6.1. Guess it's been fixed since then.

--
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] stdlib socket usage and "keepalive"

[Greg Ewing]

Jesus Cea wrote:


About controversial... keepalive are usually sent only when the
connection is 100% idle for a while, when "while" can be >15 minutes, so
the load should be "none" for regular connections.


I guess the concern would be that the keepalive probe itself
is subject to uncertain delays, so how long do you wait for
a reply before deciding that the connection is dead? If you
don't wait long enough, you could end up killing a connection
that would have come back if you had waited longer.

--
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] OS information, tags

[Nick Coghlan]

Senthil Kumaran wrote:
> On Mon, Apr 12, 2010 at 07:06:29PM +0530, Anand Balachandran Pillai wrote:
>>I am surprised to see that the bug-tracker
>> doesn't have an OS classifier or ability to add
>> tags ? Since a number of issues reported seem to
> 
> There is one. In the Components you can do a multiple select and it
> has Macintosh , Windows as options.

I think that setup dates from the Sourceforge days when we didn't have
keywords or the ability to add our own fields. Would it make sense to
put a request on the metatracker to convert these to keywords now that
they're available? Or even a separate OS field with "Windows, Mac OS X,
Linux, *BSD, Other" as the options?

While there is some Windows and Mac specific code, treating them as
separate components seems fairly unintuitive.

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] Getting an optional parameter instead of creating a socket internally

[Nick Coghlan]

Jesus Cea wrote:
> On 04/13/2010 12:47 AM, Antoine Pitrou wrote:
>> Jesus Cea  jcea.es> writes:
>>> 4. Modify client libraries to accept a new optional socket-like object
>>> as an optional parameter. This would allow things like transparent
>>> compression or encryption, or to replace the socket connection by
>>> anything else (read/write to shared memory or database, for example).
>> This could be useful too.
> 
> I have been thinking about this for years. Do you actually think this
> could be formally proposed?.

This strikes me as the best way forward (albeit far from easy to do):

1. Existing code which doesn't use the new arguments should be unaffected.

2. No changes to low level socket code, so no chance of unintended side
effects on library behaviour

3. Solves a broad class of problems (i.e. allows all sorts of tunnelling
and various socket options) rather than just this one problem.

4. Allows easier library testing with "mock" socket objects.

The problem actually reminds me of Spolsky's Law of Leaky Abstractions
essay. If the abstraction layer is going to leak anyway (and they always
do), it's best to give the developer access to all of the tools they
need to plug the hole.

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] [Python-checkins] r80025 - peps/trunk/pep-3147.txt

[Nick Coghlan]

barry.warsaw wrote:
> +It is recommended that when nothing sensible can be calculated,
> +implementations should set the `__cached__` attribute to `None`.

What (if anything) should we set __cached__ to in __main__?

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] [Python-checkins] r80025 - peps/trunk/pep-3147.txt

[Barry Warsaw]

On Apr 13, 2010, at 11:13 PM, Nick Coghlan wrote:

>barry.warsaw wrote:
>> +It is recommended that when nothing sensible can be calculated,
>> +implementations should set the `__cached__` attribute to `None`.
>
>What (if anything) should we set __cached__ to in __main__?

Good catch.  Right now (in my current branch) it is undefined.  It should be
None.

-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] OS information, tags

[Stephen J. Turnbull]

Nick Coghlan writes:

 > they're available? Or even a separate OS field with "Windows, Mac OS X,
 > Linux, *BSD, Other" as the options?

XEmacs has a multilink field "platform".  The default is "Any or all"
(mislabeled N/A), and values include hardware (currently x86, PPC,
other), OS (POSIX, Windows NT), and GUI (Windows, X11, Carbon,
TTY[sic]).  Multilink means you can have as many as you want, and no
attempt is made to enforce "one of each" or anything like that.

I don't know if the distinction between OS and GUI is as important for
Python.  And "platform" is rarely useful for us -- platform bugs tend
to be spectacular things like build breakage or crashes, and so get
attention from a much wider circle than just the platform specialists.
(Especially since the guilty party is usually a nonspecialist who
never heard of that kind of dragon before.)  So I can't really offer a
pile of relevant experience, but it seems like a good idea.

 > While there is some Windows and Mac specific code, treating them as
 > separate components seems fairly unintuitive.

Not always unintuitive.  There are some features only available on a
particular platform, then "component" sort of makes sense.  OTOH,
there are some bugs that are only available on a particular platform
even though the code is generic.  There "component" isn't very
intuitive.  In theory, I could see having both the component and the
platform fields, but probably that would require too much user
education to be worth it.
___
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] OS information, tags

[Anand Balachandran Pillai]

On Tue, Apr 13, 2010 at 6:24 PM, Nick Coghlan  wrote:

> Senthil Kumaran wrote:
> > On Mon, Apr 12, 2010 at 07:06:29PM +0530, Anand Balachandran Pillai
> wrote:
> >>I am surprised to see that the bug-tracker
> >> doesn't have an OS classifier or ability to add
> >> tags ? Since a number of issues reported seem to
> >
> > There is one. In the Components you can do a multiple select and it
> > has Macintosh , Windows as options.
>

 Thanks for pointing that out. I missed it.

 A problem seems to be that for most bugs, the filer seems to select
 just one component and leave the rest of it to bug description. When
 I searched with "Windows" component, the most recent bugs I saw
 was upto 1 week ago, where as a bug like http://bugs.python.org/issue8384
 which is a distutils issue reported on Windows is not present, because
 the reporter chose to file it under "distutils" component.


>
> I think that setup dates from the Sourceforge days when we didn't have
> keywords or the ability to add our own fields. Would it make sense to
> put a request on the metatracker to convert these to keywords now that
> they're available? Or even a separate OS field with "Windows, Mac OS X,
> Linux, *BSD, Other" as the options?
>
> While there is some Windows and Mac specific code, treating them as
> separate components seems fairly unintuitive.
>

 +1. I don't understand why Windows and Mac should come under
 "Components". It is not very obvious to the reporters also.

 Separate question: Who is in charge of bug triaging in pydev ? This is
something which I would like to help out with, if help is required :-)


>
> Cheers,
> Nick.
>
> --
> Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
> ---
>



-- 
--Anand
___
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-checkins] r80025 - peps/trunk/pep-3147.txt

[Nick Coghlan]

Barry Warsaw wrote:
> On Apr 13, 2010, at 11:13 PM, Nick Coghlan wrote:
> 
>> barry.warsaw wrote:
>>> +It is recommended that when nothing sensible can be calculated,
>>> +implementations should set the `__cached__` attribute to `None`.
>> What (if anything) should we set __cached__ to in __main__?
> 
> Good catch.  Right now (in my current branch) it is undefined.  It should be
> None.

Sounds reasonable. I ask because the various functions in runpy will
also need to cover setting that value properly.

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] OS information, tags

[Nick Coghlan]

Stephen J. Turnbull wrote:
>  > While there is some Windows and Mac specific code, treating them as
>  > separate components seems fairly unintuitive.
> 
> Not always unintuitive.  There are some features only available on a
> particular platform, then "component" sort of makes sense.  OTOH,
> there are some bugs that are only available on a particular platform
> even though the code is generic.  There "component" isn't very
> intuitive.  In theory, I could see having both the component and the
> platform fields, but probably that would require too much user
> education to be worth it.

Yep, that's where the "fairly" qualification came from. It particularly
made sense when we had all those Mac OS 9 specific modules kicking around.

This isn't something I feel strongly about - just pointing out to the
triage guys that requesting a change *is* an option if they think it
would help.

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] [Python-checkins] r80025 - peps/trunk/pep-3147.txt

[Barry Warsaw]

On Apr 14, 2010, at 12:17 AM, Nick Coghlan wrote:

>Barry Warsaw wrote:
>> On Apr 13, 2010, at 11:13 PM, Nick Coghlan wrote:
>> 
>>> barry.warsaw wrote:
 +It is recommended that when nothing sensible can be calculated,
 +implementations should set the `__cached__` attribute to `None`.
>>> What (if anything) should we set __cached__ to in __main__?
>> 
>> Good catch.  Right now (in my current branch) it is undefined.  It should be
>> None.
>
>Sounds reasonable. I ask because the various functions in runpy will
>also need to cover setting that value properly.

Right.  I'm looking at runpy now, but am less familiar with this code.  Right
now I have anything executed with -m as setting __cached__ to None, which
seems right in the simple case because the -m  doesn't appear to get
byte compiled.  Is that 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] Tuning Python dicts

[Daniel Stutzbach]

On Sat, Apr 10, 2010 at 1:06 PM, Reid Kleckner  wrote:

> Looking at dictnotes.txt, I can see that people have experimented with
> taking advantage of cache locality.  I was wondering what benchmarks
> were used to glean these lessons before I write my own.  Python
> obviously has very particular workloads that need to be modeled
> appropriately, such as namespaces and **kwargs dicts.
>

I don't know what benchmarks were used to write dictnotes.txt, but moving
forward I would recommend implementing your changes on trunk (i.e., Python
2.x) and running the Unladen Swallow Benchmarks, which you can get from the
link below:

http://code.google.com/p/unladen-swallow/wiki/Benchmarks

They are macro-benchmarks on real applications.  You will probably also want
to write some micro-benchmarks of your own so that you can pinpoint any
bottlenecks in your code and determine where you are ahead of the current
dict implementation and where you are behind.
--
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] OS information, tags

[R. David Murray]

On Tue, 13 Apr 2010 19:47:16 +0530, Anand Balachandran Pillai 
 wrote:
> On Tue, Apr 13, 2010 at 6:24 PM, Nick Coghlan  wrote:
> 
> > Senthil Kumaran wrote:
> > > On Mon, Apr 12, 2010 at 07:06:29PM +0530, Anand Balachandran Pillai
> > wrote:
> > >>I am surprised to see that the bug-tracker
> > >> doesn't have an OS classifier or ability to add
> > >> tags ? Since a number of issues reported seem to
> > >
> > > There is one. In the Components you can do a multiple select and it
> > > has Macintosh , Windows as options.
> >
> 
>  Thanks for pointing that out. I missed it.
> 
>  A problem seems to be that for most bugs, the filer seems to select
>  just one component and leave the rest of it to bug description. When
>  I searched with "Windows" component, the most recent bugs I saw
>  was upto 1 week ago, where as a bug like http://bugs.python.org/issue8384
>  which is a distutils issue reported on Windows is not present, because
>  the reporter chose to file it under "distutils" component.

Well, one generally can't depend on the submitter to get the details
right, because they often aren't familiar with our conventions.  Triage
tries to add those components when appropriate, but sometimes we forget.

The more interesting question is, do any developers search on the
windows/mac components?  My guess would be that we mostly depend on
appropriate people getting set as nosy on bugs, by themselves after
seeing it on the new bugs list, or by triage.

> > I think that setup dates from the Sourceforge days when we didn't have
> > keywords or the ability to add our own fields. Would it make sense to
> > put a request on the metatracker to convert these to keywords now that
> > they're available? Or even a separate OS field with "Windows, Mac OS X,
> > Linux, *BSD, Other" as the options?
> >
> > While there is some Windows and Mac specific code, treating them as
> > separate components seems fairly unintuitive.
> >
> 
>  +1. I don't understand why Windows and Mac should come under
>  "Components". It is not very obvious to the reporters also.

Well, on the flip side, if there were a separate OS list, we'd probably
get a lot of submitters selecting their OS when in fact the bug is
not OS specific.  So I'm not sure the problems would be any smaller
with that approach.

>  Separate question: Who is in charge of bug triaging in pydev ? This is
> something which I would like to help out with, if help is required :-)

As with just about everything else Python, a small, ad hoc team
of volunteers.  There's no one "in charge".  Anyone with 'developer'
privileges on the tracker (which means anyone with commit access, but also
non-committers who have been given it so they can do triage) can do triage.
There are a batch of us that hang out on #python-dev and also monitor the
new bugs and/or the full bugs list, and triage issues as we have time.
If you want to help out, come talk to us on #python-dev (on freenode),
and start reviewing issues and suggesting appropriate status updates.
If you help out, it won't be long before you get tracker 'developer'
privs so you can help out more.

--
R. David Murray  www.bitdance.com
___
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] OS information, tags

[R. David Murray]

On Wed, 14 Apr 2010 00:21:07 +1000, Nick Coghlan  wrote:
> Stephen J. Turnbull wrote:
> >  > While there is some Windows and Mac specific code, treating them as
> >  > separate components seems fairly unintuitive.
> > 
> > Not always unintuitive.  There are some features only available on a
> > particular platform, then "component" sort of makes sense.  OTOH,
> > there are some bugs that are only available on a particular platform
> > even though the code is generic.  There "component" isn't very
> > intuitive.  In theory, I could see having both the component and the
> > platform fields, but probably that would require too much user
> > education to be worth it.
> 
> Yep, that's where the "fairly" qualification came from. It particularly
> made sense when we had all those Mac OS 9 specific modules kicking around.
> 
> This isn't something I feel strongly about - just pointing out to the
> triage guys that requesting a change *is* an option if they think it
> would help.

It's not really a question of what Triage needs, but what the committers
as a whole would find most useful.  As I said in another note, I think
having a separate OS selection would cause just as many triage issues
as the current setup does.  So the question is, what would developers
and bug searchers/submitters find useful?

That said, it's easier to add components and keywords than it is to
add a new selection box.  I know how to do the former but not (yet)
the latter.

--
R. David Murray  www.bitdance.com
___
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] OS information, tags

[Terry Reedy]

On 4/13/2010 10:17 AM, Anand Balachandran Pillai wrote:


 >>I am surprised to see that the bug-tracker
 >> doesn't have an OS classifier or ability to add
 >> tags ? Since a number of issues reported seem to
 >
 > There is one. In the Components you can do a multiple select and it
 > has Macintosh , Windows as options.


  Thanks for pointing that out. I missed it.


Me to. Are thery really never any *nix specific bugs? There are *nix 
specific features, so bugs in those features would be.




  Separate question: Who is in charge of bug triaging in pydev ? This is
something which I would like to help out with, if help is required :-)


It is being done well now, but it is possible that some of those doing 
so could move up to patch review, or something, if there were more triagers.


I started by registering and just making unofficial triage comments like 
'behavior matches doc' followed by 'recommend closing as invalid' or 
'recommend changing to feature request' or 'recommend changing to doc 
improvement request' as I thought best. Eventually (after about a year) 
a committer noticed that he (nearly) always agreed and gave me admin 
privileges to make the changes directly. David's #python-dev suggestion 
would speed that process ;-) I might even give it a try sometime when I 
am in doubt and would otherwise not do anything. One way or the other, 
give it a try.


Terry Jan Reedy

___
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] Status of 2.7b1?

[David Bolen]

Brian Curtin  writes:

> The tests are run on a native Win32 build as compiled by VS2008. The
> functionality is Win32 specific and wouldn't work on Cygwin, so the tests
> are skipped there. I believe Cygwin is used for kicking off the tests and
> other buildbot stuff, but they don't actually run through Cygwin.

Yes, that's correct.  Cygwin is on my buildbot just for management
convenience.  The build slave happens to be started from a Cygwin bash
shell (and beneath a Cygwin-based home directory, which is why you see
it in various path references in logs), but the buildbot code itself
is responsible for executing the python process directly for testing.
And python itself is built normally with VS 2008 as a pure win32
build, no Cygwin dependency.

I did also verify over the weekend that the failures occur whether the
python_d process is started from a Cygwin bash shell or from the
normal Windows cmd process, and even if test_os is used directly,
without running through rt.bat.  The case that ran successfully was
not via test_os, but only by interactively replicating the test.

I'm back at this point, and to the extent my buildbot is the only
place currently replicating the problem, am working with Brian for
whatever access or resources might be helpful.

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

[Python-Dev] PEP 3147 ready for pronouncement and merging

[Barry Warsaw]

I am attaching the latest revision of PEP 3147 to this message, which is also
available here:

http://www.python.org/dev/peps/pep-3147/

I think the PEP is ready for pronouncement, and the patch is pretty much ready
for merging into py3k.  The only thing that I can think of that is not
implemented yet is this section on PEP 302 loaders:

PEP 302 [18]_ defined loaders have a `.get_filename()` method which
points to the `__file__` for a module.  As part of this PEP, we will
extend this API, to include a new method `.get_paths()` which will
return a 2-tuple containing the path to the source file and the path
to where the matching `pyc` file is (or would be).

I'm honestly not sure whether this is still essential, or whether the
importlib ABC changes Brett and I talked about at Pycon are still required.  I
now believe they are at best a minor part of the implementation if so.  Maybe
Brett can chime in on that.

Everything else is implemented, tested, and has undergone four rounds of
Rietveld reviews (thanks Antoine, Benjamin, Brett, and Georg!).  A fifth patch
set has been uploaded and is available here:

http://codereview.appspot.com/842043/show

This addresses all previous comments, includes some fixes from Brian Curtin
for Windows (thanks!) and fixes __main__ and -m support.  I'd like to commit
this to py3k sooner rather than later so that we can shake out any additional
issues that might crop up, without having to continue to maintain my external
branches.

Guido, what say you?
-Barry

PEP: 3147
Title: PYC Repository Directories
Version: $Revision: 80025 $
Last-Modified: $Date: 2010-04-12 22:17:40 -0400 (Mon, 12 Apr 2010) $
Author: Barry Warsaw 
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 2009-12-16
Python-Version: 3.2
Post-History: 2010-01-30, 2010-02-25, 2010-03-03, 2010-04-12


Abstract


This PEP describes an extension to Python's import mechanism which
improves sharing of Python source code files among multiple installed
different versions of the Python interpreter.  It does this by
allowing more than one byte compilation file (.pyc files) to be
co-located with the Python source file (.py file).  The extension
described here can also be used to support different Python
compilation caches, such as JIT output that may be produced by an
Unladen Swallow [1]_ enabled C Python.


Background
==

CPython compiles its source code into "byte code", and for performance
reasons, it caches this byte code on the file system whenever the
source file has changes.  This makes loading of Python modules much
faster because the compilation phase can be bypassed.  When your
source file is `foo.py`, CPython caches the byte code in a `foo.pyc`
file right next to the source.

Byte code files contain two 32-bit numbers followed by the marshaled
[2]_ code object.  The 32-bit numbers represent a magic number and a
timestamp.  The magic number changes whenever Python changes the byte
code format, e.g. by adding new byte codes to its virtual machine.
This ensures that pyc files built for previous versions of the VM
won't cause problems.  The timestamp is used to make sure that the pyc
file is not older than the py file that was used to create it.  When
either the magic number or timestamp do not match, the py file is
recompiled and a new pyc file is written.

In practice, it is well known that pyc files are not compatible across
Python major releases.  A reading of import.c [3]_ in the Python
source code proves that within recent memory, every new CPython major
release has bumped the pyc magic number.


Rationale
=

Linux distributions such as Ubuntu [4]_ and Debian [5]_ provide more
than one Python version at the same time to their users.  For example,
Ubuntu 9.10 Karmic Koala users can install Python 2.5, 2.6, and 3.1,
with Python 2.6 being the default.

This causes a conflict for Python source files installed by the
system (including third party packages), because you cannot compile a
single Python source file for more than one Python version at a time.
Thus if your system wanted to install a `/usr/share/python/foo.py`, it
could not create a `/usr/share/python/foo.pyc` file usable across all
installed Python versions.

Furthermore, in order to ease the burden on operating system packagers
for these distributions, the distribution packages do not contain
Python version numbers [6]_; they are shared across all Python
versions installed on the system.  Putting Python version numbers in
the packages would be a maintenance nightmare, since all the packages
- *and their dependencies* - would have to be updated every time a new
Python release was added or removed from the distribution.  Because of
the sheer number of packages available, this amount of work is
infeasible.

C extensions can be source compatible across multiple versions of
Python.  Compiled extension modules are usually not compatible though,
and PEP 384 [7]_ has been proposed to address this by defin

Re: [Python-Dev] Tuning Python dicts

[Reid Kleckner]

On Tue, Apr 13, 2010 at 12:12 PM, Daniel Stutzbach
 wrote:
> I don't know what benchmarks were used to write dictnotes.txt, but moving
> forward I would recommend implementing your changes on trunk (i.e., Python
> 2.x) and running the Unladen Swallow Benchmarks, which you can get from the
> link below:
>
> http://code.google.com/p/unladen-swallow/wiki/Benchmarks

I'm a contributor, actually.  ;)

> They are macro-benchmarks on real applications.  You will probably also want
> to write some micro-benchmarks of your own so that you can pinpoint any
> bottlenecks in your code and determine where you are ahead of the current
> dict implementation and where you are behind.

What I really wanted to do was to find the benchmarks for the
experiments discussed in dictnotex.txt so I could put them in the
unladen benchmark repository, which now lives at hg.python.org.

Since no one knows where they are, I think my next step will be to go
back and see who wrote what parts of that file and contact them
individually.

Reid
___
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] GSoC mentors needed

[Martin v. Löwis]

It seems the Python (core) project needs some more mentors,
to really match the proposals that we got. I don't want to post a list
of proposals here, so if you are willing to potentially mentor a
project, please join the soc2010-mentors list ASAP and/or contact Arc Riley.

Doing so would neither be a commitment nor a guarantee that you will
actually mentor a project - this depends on a lot of factors (your
interest in a specific project, Google's ultimate assigment of slots,
and so on).

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] [Python-checkins] r80025 - peps/trunk/pep-3147.txt

[Nick Coghlan]

Barry Warsaw wrote:
> On Apr 14, 2010, at 12:17 AM, Nick Coghlan wrote:
> 
>> Barry Warsaw wrote:
>>> On Apr 13, 2010, at 11:13 PM, Nick Coghlan wrote:
>> Sounds reasonable. I ask because the various functions in runpy will
>> also need to cover setting that value properly.
> 
> Right.  I'm looking at runpy now, but am less familiar with this code.  Right
> now I have anything executed with -m as setting __cached__ to None, which
> seems right in the simple case because the -m  doesn't appear to get
> byte compiled.  Is that correct?

Yeah, the only time it uses byte-compiled files is if the original
source is missing. Setting __cached__ to None for that case as well
sounds like a reasonable starting point.

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] OS information, tags

[Martin v. Löwis]

> That said, it's easier to add components and keywords than it is to
> add a new selection box.  I know how to do the former but not (yet)
> the latter.

It's not too difficult, either: edit schema.py to change the database
(roundup will automatically sync with the database), then edit
html/issue.item.html to display the field (pick one of the fields with a
similar type, and copy-paste).

Assuming this is an enumerated type, you actually need to start with
creating a new Class (in schema.py). Ignore initial_data.py, and just
define the class; then fill the enumerators through the web interface.

This is one of the areas where roundup rocks (email follow-ups being the
other one :-)

One of the roundup downsides is access control. Take a similar field
(access-control wise), and add the new field/class to all places where
the similar field is used. That will make sure that any AC bugs in the
original field will also spread to the new field :-(

HTH,
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] PEP 3147 ready for pronouncement and merging

[Guido van Rossum]

On Tue, Apr 13, 2010 at 1:21 PM, Barry Warsaw  wrote:
> I am attaching the latest revision of PEP 3147 to this message, which is also
> available here:
>
> http://www.python.org/dev/peps/pep-3147/
>
> I think the PEP is ready for pronouncement, and the patch is pretty much ready
> for merging into py3k.  The only thing that I can think of that is not
> implemented yet is this section on PEP 302 loaders:
>
>    PEP 302 [18]_ defined loaders have a `.get_filename()` method which
>    points to the `__file__` for a module.  As part of this PEP, we will
>    extend this API, to include a new method `.get_paths()` which will
>    return a 2-tuple containing the path to the source file and the path
>    to where the matching `pyc` file is (or would be).
>
> I'm honestly not sure whether this is still essential, or whether the
> importlib ABC changes Brett and I talked about at Pycon are still required.  I
> now believe they are at best a minor part of the implementation if so.  Maybe
> Brett can chime in on that.
>
> Everything else is implemented, tested, and has undergone four rounds of
> Rietveld reviews (thanks Antoine, Benjamin, Brett, and Georg!).  A fifth patch
> set has been uploaded and is available here:
>
> http://codereview.appspot.com/842043/show
>
> This addresses all previous comments, includes some fixes from Brian Curtin
> for Windows (thanks!) and fixes __main__ and -m support.  I'd like to commit
> this to py3k sooner rather than later so that we can shake out any additional
> issues that might crop up, without having to continue to maintain my external
> branches.
>
> Guido, what say you?

Give me a couple of days; but I don't expect any problems given how
the earlier discussion went. If you didn't hear from me by Friday go
ahead and merge.

> -Barry

-- 
--Guido van Rossum (python.org/~guido)
___
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] Use surrogates for Python import

[Victor Stinner]

Hi,

Python3 refuses to start with LANG=C if it's installed in a non-ASCII 
directory. I wrote a patch fixing this issue, but it changes a lot of code and 
I would like your opinion.

The main part changes import to use surrogateescape everywhere (find_module, 
load_source_module, null importer, zip importer, etc.). Other files have to be 
adapted:

 - traceback.c (tb_printinternal),
 - ast.c (ast_error_finish),
 - compile.c (compiler_error),
 - bltinmodule.c (builtin_compile),
 - _warnings.c (show_warning),
 - tokenizer.c (fp_setreadl),
 - ...

It fixes also calculate_path(): sys.path may also contains directories using 
surrogates.

Should I continue to work on this, or is it a bad idea to use surrogates in 
filenames used in Python imports?

--

Related issue: #8242. The patch attached to this issue is a work-in-progress, 
I plan to cleanup it and to split it in small patches. It contains extra 
changes to fix many modules and tests if the current directory is not 
decodable.

-- 
Victor Stinner
http://www.haypocalc.com/
___
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] patch for review: unittest ImportError handling

[Chris Jerdonek]

Hi folks,

I have a patch to the unittest module for review here:

http://bugs.python.org/issue7559#msg102801

(There have already been a couple rounds of discussion on how to best
fix this.)

This is my first patch, so any feedback is appreciated.

Thanks,
--Chris
___
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] Fwd: Broken link to download (Mac OS X)

[Steve Holden]

Why is it unavoidable that the Mac build will languish behind others?
Are we supporting MacOs or aren't we? If we are, why isn't the creation
of the build a part of the release process?

Clearly it's not a priority given that nobody has seen fit to (or had
time to) reply to this mail in three weeks.

regards
 Steve

webmas...@python.org wrote:
> Hey all,
> 
> This seems to happen whenever we do a new release (we've had a couple of
> emails to webmas...@python.org about it since 2.6.5 was released). The
> main download page for Python has a broken link for the Mac installer
> (because it hasn't been built yet I assume):
> 
> http://python.org/download/
> 
> The link 404s, with no explanation or alternate link - so for the casual
> user who wants to install Python 2.6 on Mac OS X they are
> sorely-out-of-luck.
> 
> Not being able to provide a mac installer at the same time as other
> platforms is one thing (and I accept that is unavoidable), breaking the
> download links for Mac users for unspecified lengths of time is just bad
> practise. If we create a new stable release without a Mac installer can
> we at least provide a brief explanation and link to the *previous
> version* until the new version is ready?
> 
> All the best,
> 
> Michael
> 
>  Original Message 
> Subject:  Broken link to down
> Date: Sun, 21 Mar 2010 13:40:36 +
> From: Ben Hodgson 
> To:   webmas...@python.org
> 
> 
> 
> Hey there,
> 
> In case you don't know, the link on http://www.python.org/download/ to
> the Python 2.6.5 Mac Installer Disk Image
> (http://www.python.org/ftp/python/2.6.5/python-2.6.5_macosx10.3.dmg) is
> broken.
> 
> Cheers,
> Ben
> 
> --
> Ben Hodgson
> http://benhodgson.com/
> 


-- 
Steve Holden   +1 571 484 6266   +1 800 494 3119
See PyCon Talks from Atlanta 2010  http://pycon.blip.tv/
Holden Web LLC http://www.holdenweb.com/
UPCOMING EVENTS:http://holdenweb.eventbrite.com/

___
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] patch for review: __import__ documentation

[Chris Jerdonek]

Here is another patch for review:

http://bugs.python.org/issue8370

This is a trivial fix to the 2.6 and 2.7 documentation.

Thanks,
--Chris
___
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] Fwd: Broken link to download (Mac OS X)

[Tres Seaver]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Steve Holden wrote:
> Why is it unavoidable that the Mac build will languish behind others?
> Are we supporting MacOs or aren't we? If we are, why isn't the creation
> of the build a part of the release process?
> 
> Clearly it's not a priority given that nobody has seen fit to (or had
> time to) reply to this mail in three weeks.

Maybe the PSF should make it a priority by funding acquisition of the
appropriate proprietary hardware (Mac / Windows) for the release
manager.  Otherwise the avaialbility of binaries is going to lag source
releases forever.



Tres.
- --
===
Tres Seaver  +1 540-429-0999  tsea...@palladion.com
Palladion Software   "Excellence by Design"http://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkvFPQ0ACgkQ+gerLs4ltQ5EkQCfTCMQTefF8dnjn2sZ8fHgJNNc
HD8Ani13Nq8q1zaG8ttlpoZ/gZ3tQ3Ln
=DuRD
-END 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] Fwd: Broken link to download (Mac OS X)

[Steve Holden]

Tres Seaver wrote:
> Steve Holden wrote:
>> Why is it unavoidable that the Mac build will languish behind others?
>> Are we supporting MacOs or aren't we? If we are, why isn't the creation
>> of the build a part of the release process?
> 
>> Clearly it's not a priority given that nobody has seen fit to (or had
>> time to) reply to this mail in three weeks.
> 
> Maybe the PSF should make it a priority by funding acquisition of the
> appropriate proprietary hardware (Mac / Windows) for the release
> manager.  Otherwise the avaialbility of binaries is going to lag source
> releases forever.
> 
Thanks for your note. One of the reasons I took the trouble to comment
on the issue was to determine whether resources are needed.

Generally I regard it as the PSF's job to respond to requests for
resources from the dev team, not to tell them how to do the work they
already excel at.

We did, a while ago, accept a hardware donation from Apple. If we need
more Mac hardware I will be happy to ask the Infrastructure Committee to
look into it, but I'd suggest we need guidance from someone actually
involved in the build work to ensure we get maximum utility out of any
investment.

I do think it makes us look bad to have one supported platform lag the
others, but it wasn't obvious to me whether hardware alone was the
reason. If it is, the fix should be relatively simple.

regards
 Steve
-- 
Steve Holden   +1 571 484 6266   +1 800 494 3119
See PyCon Talks from Atlanta 2010  http://pycon.blip.tv/
Holden Web LLC http://www.holdenweb.com/
UPCOMING EVENTS:http://holdenweb.eventbrite.com/

___
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] Fwd: Broken link to download (Mac OS X)

[Ned Deily]

In article ,
 Steve Holden  wrote:

> Why is it unavoidable that the Mac build will languish behind others?
> Are we supporting MacOs or aren't we? If we are, why isn't the creation
> of the build a part of the release process?
> 
> Clearly it's not a priority given that nobody has seen fit to (or had
> time to) reply to this mail in three weeks.

Wasn't that problem fixed weeks ago?  The installer image has been 
available there since several days after the release.  And the link 
seems fine now.

-- 
 Ned Deily,
 n...@acm.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] Decimal <-> float comparisons in py3k.

[Steve Holden]

Guido van Rossum wrote:
> On Tue, Mar 16, 2010 at 2:32 PM, Steven D'Aprano  wrote:
>> But mixed arithmetic runs into the problem, what do you want the result
>> type to be? Given (say) decimal+float, returning either a Decimal or a
>> float will be the wrong thing to do some of the time, so better to
>> prohibit mixed arithmetic and let folks handle their own conversions.
>> So +1 on continuing to prohibit mixed arithmetic.
> 
> I'm not disagreeing, but I really wonder, what is the value of
> supporting mixed comparisons then? Just because you *can* assign a
> meaning to it doesn't mean you should.
> 
> OTOH I'm sure a lot of people would like to see mixed arithmetic
> supported, the PEP be damned, and they would probably be happy with
> any simple rule about the return type even if it's not always ideal. I
> note that there are cases where converting a long to a float also is
> the wrong thing to do, and yet mixed long/float operations always
> return floats.

I suspect this latter behavior is a throwback to the days when
conversion of an integer to a float was guaranteed not to cause
overflow. With the extension of the integer type to longs that theory
went out of the window, and with it the previously manageable "widening"
that took place.

> If you are amenable to this argument, I would propose
> to make the result of mixed operations return a Decimal, since in some
> "intuitive complexity" sense an int is a simpler type than a float and
> a float is a simpler type than a Decimal -- so results return the more
> complex type. But my intuition on this isn't super strong and I could
> live with always returning a float as well -- there are always casts
> to force the issue.
> 
Alas Python now supports so many number systems that there is no longer
a rational (in the non-numerical sense) ordering of the systems which
allows a linear progression from one to the next. It therefore behooves
us to consider the implications of such a decision *very* carefully.
intuition alone (even yours, which I would back against most people's)
may not suffice.

regards
 Steve
-- 
Steve Holden   +1 571 484 6266   +1 800 494 3119
See PyCon Talks from Atlanta 2010  http://pycon.blip.tv/
Holden Web LLC http://www.holdenweb.com/
UPCOMING EVENTS:http://holdenweb.eventbrite.com/

___
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] Fwd: Broken link to download (Mac OS X)

[Martin v. Löwis]

> Why is it unavoidable that the Mac build will languish behind others?

Because of lack of volunteers, and expertise (i.e. the experts lack time).

> Are we supporting MacOs or aren't we?

We aren't. Strictly speaking, "we" (python-dev) "support" nothing (in
the sense that "we" can promise a support hotline, service contracts, or
 anything in that respect). That includes timely availability of stuff.
If you want Python "support" on MacOS, contact Apple, ActiveState, or
any other company that provides actual support.

In a wider sense of "to support", MacOS is certainly supported by
Python. There is everything in the source code that you need to make
Python run on a Mac. Just download the sources and compile them yourself.

> Clearly it's not a priority given that nobody has seen fit to (or had
> time to) reply to this mail in three weeks.

That is not surprising: none of the webmaster people would be able to
answer the question. python-dev is indeed the right place to ask.

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] Fwd: Broken link to download (Mac OS X)

[Martin v. Löwis]

Tres Seaver wrote:
> Steve Holden wrote:
>> Why is it unavoidable that the Mac build will languish behind others?
>> Are we supporting MacOs or aren't we? If we are, why isn't the creation
>> of the build a part of the release process?
> 
>> Clearly it's not a priority given that nobody has seen fit to (or had
>> time to) reply to this mail in three weeks.
> 
> Maybe the PSF should make it a priority by funding acquisition of the
> appropriate proprietary hardware (Mac / Windows) for the release
> manager.  Otherwise the avaialbility of binaries is going to lag source
> releases forever.

Tres,

can you be more explicit? How would such hardware help (whom specifically)?

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] Fwd: Broken link to download (Mac OS X)

[Martin v. Löwis]

> Wasn't that problem fixed weeks ago?  The installer image has been 
> available there since several days after the release.  And the link 
> seems fine now.

The inherent problem remains. There is no binary for 2.7b1, for example.
The last binaries produced in the 2.7 testing process were for 2.7a2.

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] Fwd: Broken link to download (Mac OS X)

[Steve Holden]

Martin v. Löwis wrote:
>> Why is it unavoidable that the Mac build will languish behind others?
> 
> Because of lack of volunteers, and expertise (i.e. the experts lack time).
> 
>> Are we supporting MacOs or aren't we?
> 
> We aren't. Strictly speaking, "we" (python-dev) "support" nothing (in
> the sense that "we" can promise a support hotline, service contracts, or
>  anything in that respect). That includes timely availability of stuff.
> If you want Python "support" on MacOS, contact Apple, ActiveState, or
> any other company that provides actual support.
> 
OK. I should confirm that I mean "support" in your wider sense below.

> In a wider sense of "to support", MacOS is certainly supported by
> Python. There is everything in the source code that you need to make
> Python run on a Mac. Just download the sources and compile them yourself.
> 
And yet we don't regard the Windows release as complete until you have
built the binaries (for which service you deserve many thanks, by the way).

Is the Mac platform one on which users will be happy to compile from
source? I know its users are savvier than Windows users, and have a
better tool set available to them, but they still seem to expect
downloadable installers.

>> Clearly it's not a priority given that nobody has seen fit to (or had
>> time to) reply to this mail in three weeks.
> 
> That is not surprising: none of the webmaster people would be able to
> answer the question. python-dev is indeed the right place to ask.
> 
I thought I'd picked this thread off python-dev. What point am I not
understanding here?

regards
 Steve
-- 
Steve Holden   +1 571 484 6266   +1 800 494 3119
See PyCon Talks from Atlanta 2010  http://pycon.blip.tv/
Holden Web LLC http://www.holdenweb.com/
UPCOMING EVENTS:http://holdenweb.eventbrite.com/
___
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] Fwd: Broken link to download (Mac OS X)

[Martin v. Löwis]

>> In a wider sense of "to support", MacOS is certainly supported by
>> Python. There is everything in the source code that you need to make
>> Python run on a Mac. Just download the sources and compile them yourself.
>>
> And yet we don't regard the Windows release as complete until you have
> built the binaries (for which service you deserve many thanks, by the way).

This phenomenon exists for a lot of other systems, as well. For example,
we also support Solaris, but stopped providing Solaris binaries since
Python 1.5 (when I last built binaries for Das Python-Buch). People
still can get Solaris binaries from ActiveState or Sunfreeware; Sun also
ships Python as part of the system.

> Is the Mac platform one on which users will be happy to compile from
> source? I know its users are savvier than Windows users, and have a
> better tool set available to them, but they still seem to expect
> downloadable installers.

The major difference in the "do it yourself" attitude is that Mac user
get a compiler for free, as part of the operating system release,
whereas for Windows, they have to pay for it (leaving alone VS Express
for the moment).

However, the real difference is motivation for contribution to open
source projects. You normally contribute to scratch an itch.
Unfortunately, these binaries don't come out such a motiviation. So the
release manager roles are either altruistic, or rely on extrinsic
motivations (money, reputation).

>>> Clearly it's not a priority given that nobody has seen fit to (or had
>>> time to) reply to this mail in three weeks.
>> That is not surprising: none of the webmaster people would be able to
>> answer the question. python-dev is indeed the right place to ask.
>>
> I thought I'd picked this thread off python-dev. What point am I not
> understanding here?

Maybe I misunderstood. I thought you copied it from the webmaster list
(as the original To indicated). I don't recall having it seen on
python-dev, but I kill many messages to python-dev without reading them.

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] Fwd: Broken link to download (Mac OS X)

[Paul Rudin]

"Martin v. Löwis"  writes:

> The major difference in the "do it yourself" attitude is that Mac user
> get a compiler for free, as part of the operating system release,
> whereas for Windows, they have to pay for it (leaving alone VS Express
> for the moment).

JOOI why ignore the express versions of the MS compilers? All (I think)
MS compilers are available for free in command line versions - it's the
GUI tools you pay for.

___
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