Re: [Python-Dev] Official citation for Python

[Jeremy Hylton]

I wanted to start with an easy answer that is surely unsatisfying:
http://blog.apastyle.org/apastyle/2015/01/how-to-cite-software-in-apa-style.html

APA style is pretty popular, and it says that standard software doesn't
need to be specified. Standard software includes "Microsoft Word, Java, and
Adobe Photoshop." So I'd say Python fits well in that category, and doesn't
need to be cited.

I said you wouldn't be satisfied...

On Sat, Sep 15, 2018 at 11:02 AM Jacqueline Kazil 
wrote:

> I just got caught up on the thread. This is a really great discussion.
> Thank you for all the contributions.
>
> Before we get into the details, let's go back to the main use case we are
> trying to solve.
> *As a user, I am writing an academic paper and I need to cite Python. *
>

The goal here is ambiguous. Python means many things--a language described
by the language specification, the source code of a particular
implementation of the language (Python often refers to C Python), a
particular binary release of the implementation of the language (Python
1.5.2 for Windows). Which one is relevant in the context of the paper? If
you're talking about a bug in timsort in a particular version of C Python,
then you probably want to cite that specific version of the implementation.

I suspect the most common goal for a citation is just to describe the
language "in general" where 1.5.2 or 3.7.0 and Jython or CPython are all
details that don't matter. In that case I'd cite the language
specification. We're talking about putting a citation in a paper (a written
source) and the written language specification captures what we think of as
essential for the language. If you want to cite Turing's proof of the
undecidability of the halting problem, you'd cite the paper where he wrote
it down (in Proceedings of the London Mathematical Society). If you want to
cite a programming language in the abstract, cite the specification that
describes it.

I think style guides are relevant here. They give guidance on how to cite
an item based on its category. For example, the MLA style guide describes
how to cite a digital file, a physical object, and many other things. My
favorite example under "physical object" is "Physical objects found
online." (Think about it :-).

There's some discussion of how to cite source code here:
http://integrity.mit.edu/handbook/writing-code. Notably this is talking
about citing source code in the context of other source code, and it mostly
recommends using URLs. If you wanted to cite a particular piece of source
code in an written article, you'd probably follow one of the approaches for
citing online resources. Try to identify who / when / what / where. For
example MLA style for a blog post would be : Editor, screen name, author,
or compiler name (if available). “Posting Title.” Name of Site, Version
number (if available), Name of institution/organization affiliated with the
site (sponsor or publisher), URL. Date of access. You could cite a
particular source file this way or a particular source release.

The date usually refers to the original publication date. I think that was
with the 1.0 release, although I'm not sure. I'd probably pick that date,
but someone can correct me if there's an earlier date. It would suggest
somehow that current Python and the original Python were mostly the same
thing, which is an idea I like.

van Rossum, Guido (1994). "The Python Language Reference". Python Software
Foundation, https://docs.python.org/reference/index.html. Retrieved 16
September 2018.

I'd say that's all settled. If anyone asks you, "How can you be sure that
settles it?" You can answer, "Some guy said it on a mailing list." And then
you can site the message:

Jeremy Hylton. "[Python-Dev] Official citation for Python." Sep. 17, 2018.
python-dev, https://mail.python.org/mailman/listinfo/python-dev. Accessed
18 September 2018.

Jeremy


> Let's throw reproducibility out the window for now (<--- something I never
> thought I would say), because that should be captured in the code, not in
> the citations.
>
> So, if we don't need the specific version of Python, then maybe creating
> one citation is all we need.
> And that gives it some good Google juice as well.
>
> Thoughts?
>
> (Once we nail down one or many, I think we can then move into the details
> of the content of the citation.)
>
> -Jackie
>
> On Thu, Sep 13, 2018 at 12:47 AM Wes Turner  wrote:
>
>> There was a thread about adding __cite__ to things and a tool to collect
>> those citations awhile back.
>>
>> "[Python-ideas] Add a __cite__ method for scientific packages"
>> http://markmail.org/thread/rekmbmh64qxwcind
>>
>> Which CPython source file should contain this __cite__ value?
>>
>> ... On a related note, you should ask the list admin to append a

Re: [Python-Dev] Does anyone use CALL_PROFILE special build?

[Jeremy Hylton]

I don't think there's any need to keep this feature. I hope we have better
ways to profile function and method calls now than we did when this code
was submitted.

Jeremy

On Sat, Nov 26, 2016 at 3:34 AM Raymond Hettinger <
raymond.hettin...@gmail.com> wrote:

>
> > On Nov 25, 2016, at 1:28 AM, Victor Stinner 
> wrote:
> >
> > I would like to completely remove the feature to be able to implement
> > further optimizations.
>
> This seems reasonable to me.  I've never used or needed this special
> build; StackOverflow has no mention of it; and a Google search comes up
> nearly empty.   That said, it might be worthwhile to check with Jeremy to
> get his thoughts before removing his code.
>
>
> Raymond
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Modifying Grammar/grammar and other foul acts

[Jeremy Hylton]

On Sat, Mar 6, 2010 at 11:27 AM, Gregg Lind gregg.l...@gmail.com wrote:
 Python-devs,

 I'm writing to you for some help in understanding the Python grammar.  As an
 excuse to deep dive into Python's tokenizer / grammar, I decided (as a
 hideous, hideous joke) to want to allow braces where colons are allowed (as
 flow control).

 Starting from PEP 306 (and branch r311), I hacked on Grammar/Grammer

 As a first example:

 funcdef: ('def' NAME parameters ['-' test] ':' suite |
   'def' NAME parameters ['-' test] '{' suite '}' )

 I reran Parser/pgen and the dfa changes, but python (3.1) when recompiled,
 throws errors on things like:

 def a() { None }

 Strangely enough:

 lambdef: ( 'lambda' [varargslist] ':' test  |
    'lambda' [varargslist] '{' test '}' )

 works fine!  I this simplely some difference between test and suite.

 I have tried tackling this with gdb, looking at err_input clearly isn't
 enough.

     (gdb) break err_input
     (gdb) break PyParser_ASTFromString
     import sys
     b = compile(def a() {pass},sys.stdout,single)
     # yet a simple grammar fix is enough for this!
     c = compile(lambda x {None},sys.stdout,single)

 I'm in over my head!

You don't say what errors occur when you try to compile strings in
your new language.  You may have changed the Grammar, which allows you
to tokenize the input.  That isn't enough to get the input to compile.
 You also need to change the compiler to understand the new tokens.

Jeremy

 Any insights / help would be appreciated.  Full-on flaming is also
 appropriate, but would be less appreciated.

 Specific questions

 1.)  I assume the Grammar/grammar is read top to bottom.  Confirm?
 2.)  More help figuring out how to debug what python *thinks* it's seeing
 when it see def a() {pass}.  It's not getting to the ast construction
 stage, as near as I can tell.  What additional breakpoints can I set to see
 where it's failing.

 Gregg L.


 ___
 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/jeremy%40alum.mit.edu


___
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] question about docstring formatting

[Jeremy Hylton]

A question came up at work about docstring formatting.  It relates to
the description of the summary line in PEP 257.

http://www.python.org/dev/peps/pep-0257/
Multi-line docstrings consist of a summary line just like a
one-line docstring, followed by a blank line, followed by a more
elaborate description. The summary line may be used by automatic
indexing tools; it is important that it fits on one line and is
separated from the rest of the docstring by a blank line. The summary
line may be on the same line as the opening quotes or on the next
line. The entire docstring is indented the same as the quotes at its
first line (see example below).

It says that the summary line may be used by automatic indexing tools,
but is there any evidence that such a tool actually exists?  Or was
there once upon a time?  If there are no such tools, do we still think
that it is important that it fits on line line?

Jeremy
___
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] issue5578 - explanation

[Jeremy Hylton]

I posted in the bug report, but repeating here:  I don't remember why
exec in a nested function changed either.  It would help if someone
could summarize why we made the change.  (I hope I didn't do it 0.2
wink.)

Jeremy

On Tue, Mar 31, 2009 at 11:36 PM, Maciej Fijalkowski fij...@gmail.com wrote:
 Because classes have now it's own local scope (according to Martin)

 It's not about exec in class, it's about exec in class in nested function.

 On Wed, Apr 1, 2009 at 5:25 AM, Guido van Rossum gu...@python.org wrote:
 Well hold on for a minute, I remember we used to have an exec
 statement in a class body in the standard library, to define some file
 methods in socket.py IIRC.  It's a totally different case than exec in
 a nested function, and I don't believe it should be turned into a
 syntax error at all. An exec in a class body is probably meant to
 define some methods or other class attributes. I actually think the
 2.5 behavior is correct, and I don't know why it changed in 2.6.

 --Guido

 On Tue, Mar 31, 2009 at 8:15 PM, Maciej Fijalkowski fij...@gmail.com wrote:
 So. The issue was closed and I suppose it was closed by not entirely
 understanding
 the problem (or I didn't get it completely).

 The question is - what the following code should do?

 def f():
  a = 2
  class C:
    exec 'a = 42'
    abc = a
  return C

 print f().abc

 (quick answer - on python2.5 it return 42, on python 2.6 and up it
 returns 2, the patch changes
 it to syntax error).

 I would say that returning 2 is the less obvious thing to do. The
 reason why IMO this should
 be a syntax error is this code:

 def f():
  a = 2
  def g():
    exec 'a = 42'
    abc = a

 which throws syntax error.

 Cheers,
 fijal
 ___
 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/guido%40python.org




 --
 --Guido van Rossum (home page: http://www.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/jeremy%40alum.mit.edu

___
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] issue5578 - explanation

[Jeremy Hylton]

Eeek, I think it was me.  Part of the AST changes involved raising a
SyntaxError when exec was used in a scope that had a free variable,
since the behavior is pretty much undefined.  If the compiler decides
a variable is free, then it can't be assigned to in the function body.
 The compiled exec code can't know whether the variable is local or
free in the exec context, only that it should generate a STORE_NAME
opcode.  The STORE_NAME can't possibly work.

It looks like I did a bad job of documenting the change, though.  I
had forgotton about it ,because it was three or four years ago.

It looks like the same exception should be raised for the class statement.

Jeremy



On Wed, Apr 1, 2009 at 11:00 AM, R. David Murray rdmur...@bitdance.com wrote:
 On Wed, 1 Apr 2009 at 13:12, Chris Withers wrote:

 Guido van Rossum wrote:

  Well hold on for a minute, I remember we used to have an exec
  statement in a class body in the standard library, to define some file
  methods in socket.py IIRC.

 But why an exec?! Surely there must be some other way to do this than an
 exec?

 Maybe, but this sure is gnarly code:

    _s = (def %s(self, *args): return self._sock.%s(*args)\n\n
          %s.__doc__ = _realsocket.%s.__doc__\n)
    for _m in _socketmethods:
        exec _s % (_m, _m, _m, _m)
    del _m, _s

 Guido's memory is good, that's from the _socketobject class in
 socket.py.

 --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/jeremy%40alum.mit.edu

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

[Jeremy Hylton]

4631 should be a release blocker.  I'll have a bit of time on Monday
and Tuesday to wrap it up.

Jeremy

On Fri, Dec 19, 2008 at 5:28 PM, Barry Warsaw ba...@python.org wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 I'd like to get Python 3.0.1 out before the end of the year.  There are no
 showstoppers, but I haven't yet looked at the deferred blockers or the
 buildbots.

 Do you think we can get 3.0.1 out on December 24th?  Or should we wait until
 after Christmas and get it out, say on the 29th?  Do we need an rc?

 This question goes mostly to Martin and Georg.  What would work for you
 guys?

 - -Barry

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

 iQCVAwUBSUwgEXEjvBPtnXfVAQIthgP7BDS6xfBHhADKc50ANvZ5aAfWhGSU9GH/
 DR+IRduVmvosu9gm92hupCOaLCN4IbtyFx27A8LQuPNVc4BVrhWfDKDSzpxO2MJu
 xLJntkF2BRWODSbdrLGdZ6H6WDT0ZAhn6ZjlWXwxhGxQ5FwEJb7moMuY7jAIEeor
 5n6Ag5zT+e8=
 =oU/g
 -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/jeremy%40alum.mit.edu

___
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 3.0 urllib fails with chunked HTTP responses

[Jeremy Hylton]

On Wed, Dec 17, 2008 at 1:05 PM, Guido van Rossum gu...@python.org wrote:
 The inheritance from io.RawIOBase seems fine.

There is a small problem with the interaction between HTTPResponse and
RawIOBase, but I think the problem is more on the http side.  You may
recall that the HTTP code has a habit of closing the connection for
you.  In a variety of cases, once you've read the last bytes of the
response, the HTTPResponse object calls its own close() method.  This
interacts poorly with RawIOBase, because it raises a ValueError for
any operation on a closed io object.  This prevents iterators from
working correctly.  The iterator implementation expects the final call
to readline() to return an empty string and converts that to a
StopIteration.  Instead, it's seeing a ValueError that propagates out.

It's always been odd to me that the connection closed itself.  It's
going to be tricky to fix the current bug (chunked responses) and keep
the self-closing behavior, but I worry that change the self-closing
behavior too dramatically isn't appropriate for a bug fix.  Will look
some more at this tomorrow.

Jeremy

 --Guido van Rossum (home page: http://www.python.org/~guido/)



 On Mon, Dec 15, 2008 at 11:19 AM, Jeremy Hylton jer...@alum.mit.edu wrote:
 I have a patch that appears to fix this bug
 http://bugs.python.org/file12361/urllib-chunked.diff
 but I'm not sure about its interaction with the io module and
 RawIOBase.  Is there a new IO expert who could take a look at it for
 me?

 Jeremy

 On Sun, Dec 14, 2008 at 11:06 PM, Jeremy Hylton jer...@alum.mit.edu wrote:
 This bug is pretty serious, because urllib will insert garbage into
 the application-visible data for a chunked response.  It simply
 ignores the fact that it's reading a chunked response and includes the
 chunked header data is payload data.  The original bug was reported in
 September, but no one noticed it.  It was reported again recently.

 http://bugs.python.org/issue3761
 http://bugs.python.org/issue4631

 I suspect we'd want to get a 3.0.1 out as soon as this is fixed, but
 that's not my call.

 Jeremy

 ___
 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/guido%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] Python 3.0 urllib fails with chunked HTTP responses

[Jeremy Hylton]

On Thu, Dec 18, 2008 at 12:27 PM, Guido van Rossum gu...@python.org wrote:
 It sounds like the self-closing is an implementation detail, meant to
 make sure the socket is closed as early as possible (which I suppose
 is a good thing if there's a server waiting for the final ACK on the
 other side). Perhaps it should not use close() but something slightly
 lower level that affects the socket directly?

That's what I'm thinking, too.  I had 10 minutes last night after the
kids went to bed, and my first attempt didn't work :-).

Jeremy


 --Guido van Rossum (home page: http://www.python.org/~guido/)



 On Thu, Dec 18, 2008 at 5:22 AM, Jeremy Hylton jer...@alum.mit.edu wrote:
 On Wed, Dec 17, 2008 at 1:05 PM, Guido van Rossum gu...@python.org wrote:
 The inheritance from io.RawIOBase seems fine.

 There is a small problem with the interaction between HTTPResponse and
 RawIOBase, but I think the problem is more on the http side.  You may
 recall that the HTTP code has a habit of closing the connection for
 you.  In a variety of cases, once you've read the last bytes of the
 response, the HTTPResponse object calls its own close() method.  This
 interacts poorly with RawIOBase, because it raises a ValueError for
 any operation on a closed io object.  This prevents iterators from
 working correctly.  The iterator implementation expects the final call
 to readline() to return an empty string and converts that to a
 StopIteration.  Instead, it's seeing a ValueError that propagates out.

 It's always been odd to me that the connection closed itself.  It's
 going to be tricky to fix the current bug (chunked responses) and keep
 the self-closing behavior, but I worry that change the self-closing
 behavior too dramatically isn't appropriate for a bug fix.  Will look
 some more at this tomorrow.

 Jeremy

 --Guido van Rossum (home page: http://www.python.org/~guido/)



 On Mon, Dec 15, 2008 at 11:19 AM, Jeremy Hylton jer...@alum.mit.edu wrote:
 I have a patch that appears to fix this bug
 http://bugs.python.org/file12361/urllib-chunked.diff
 but I'm not sure about its interaction with the io module and
 RawIOBase.  Is there a new IO expert who could take a look at it for
 me?

 Jeremy

 On Sun, Dec 14, 2008 at 11:06 PM, Jeremy Hylton jer...@alum.mit.edu 
 wrote:
 This bug is pretty serious, because urllib will insert garbage into
 the application-visible data for a chunked response.  It simply
 ignores the fact that it's reading a chunked response and includes the
 chunked header data is payload data.  The original bug was reported in
 September, but no one noticed it.  It was reported again recently.

 http://bugs.python.org/issue3761
 http://bugs.python.org/issue4631

 I suspect we'd want to get a 3.0.1 out as soon as this is fixed, but
 that's not my call.

 Jeremy

 ___
 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/guido%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] Python 3.0 urllib fails with chunked HTTP responses

[Jeremy Hylton]

I have a patch that appears to fix this bug
http://bugs.python.org/file12361/urllib-chunked.diff
but I'm not sure about its interaction with the io module and
RawIOBase.  Is there a new IO expert who could take a look at it for
me?

Jeremy

On Sun, Dec 14, 2008 at 11:06 PM, Jeremy Hylton jer...@alum.mit.edu wrote:
 This bug is pretty serious, because urllib will insert garbage into
 the application-visible data for a chunked response.  It simply
 ignores the fact that it's reading a chunked response and includes the
 chunked header data is payload data.  The original bug was reported in
 September, but no one noticed it.  It was reported again recently.

 http://bugs.python.org/issue3761
 http://bugs.python.org/issue4631

 I suspect we'd want to get a 3.0.1 out as soon as this is fixed, but
 that's not my call.

 Jeremy

___
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] Python 3.0 urllib fails with chunked HTTP responses

[Jeremy Hylton]

This bug is pretty serious, because urllib will insert garbage into
the application-visible data for a chunked response.  It simply
ignores the fact that it's reading a chunked response and includes the
chunked header data is payload data.  The original bug was reported in
September, but no one noticed it.  It was reported again recently.

http://bugs.python.org/issue3761
http://bugs.python.org/issue4631

I suspect we'd want to get a 3.0.1 out as soon as this is fixed, but
that's not my call.

Jeremy
___
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-3000] Merging mailing lists

[Jeremy Hylton]

On Thu, Dec 4, 2008 at 2:36 AM, Martin v. Löwis [EMAIL PROTECTED] wrote:
 I would like to merge mailing lists, now that the design and first
 implementation of Python 3000 is complete. In particular, I would
 like to merge the python-3000 mailing list back into python-dev,
 and the python-3000-checkins mailing list back into python-checkins.
 The rationale is to simplify usage of the lists, and to avoid
 cross-postings.

+1

 To implement this, all subscribers of the 3000 mailing lists would
 be added to the trunk mailing lists (avoiding duplicates, of course),
 and all automated messages going to python-3000-checkins would then
 be directed to the trunk lists. The 3000 mailing lists would change
 into read-only mode (i.e. primarily leaving the archives behind).

 Any objections?

No

Jeremy


 Regards,
 Martin
 ___
 Python-3000 mailing list
 [EMAIL PROTECTED]
 http://mail.python.org/mailman/listinfo/python-3000
 Unsubscribe: 
 http://mail.python.org/mailman/options/python-3000/jeremy%40alum.mit.edu

___
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] Merging flow

[Jeremy Hylton]

On Thu, Dec 4, 2008 at 10:12 AM, Christian Heimes [EMAIL PROTECTED] wrote:
 Several people have asked about the patch and merge flow. Now that Python
 3.0 is out it's a bit more complicated.

 Flow diagram
 

 trunk --- release26-maint
   \-  py3k   --- release30-maint


 Patches for all versions of Python should land in the trunk. They are then
 merged into release26-maint and py3k branches. Changes for Python 3.0 are
 merged via the py3k branch.

You say they are then merged.  Does that mean if I commit something
on the trunk, someone else will merge it for me?  Or do I need to do
it?

The library is vastly different between 2.x and 3.x.  I'm personally
aware of the many changes related to httplib / urllib / xmlrpclib.
I'm worried that it will be hard to decide how to merge things
between the two versions.

Jeremy

 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/jeremy%40alum.mit.edu

___
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] Summary of Python tracker Issues

[Jeremy Hylton]

I wanted to ask a policy question on the bug tracker.  What are we
doing with bugs filed against Python 2.4?
This bug http://bugs.python.org/issue1208304 reports a fd leak in
Python 2.4, which doesn't exist in the head.  Since Python 2.4 is in
security-fix only mode, is it fair to close this with a won't fix?

A meta-question:  Is there a document that has any tips on how to
handle bug reports?  It might be helpful to have a list of hints or
policy decisions to help people decide what to do with bugs.

Jeremy

On Fri, Nov 21, 2008 at 12:06 PM, Python tracker [EMAIL PROTECTED] wrote:

 ACTIVITY SUMMARY (11/14/08 - 11/21/08)
 Python tracker at http://bugs.python.org/

 To view or respond to any of the issues listed below, click on the issue
 number.  Do NOT respond to this message.


  2194 open (+35) / 14007 closed (+18) / 16201 total (+53)

 Open issues with patches:   728

 Average duration of open issues: 712 days.
 Median duration of open issues: 2043 days.

 Open Issues Breakdown
   open  2177 (+35)
 pending17 ( +0)

 Issues Created Or Reopened (56)
 ___

 Tkinter binding involving Control-spacebar raises unicode error  11/18/08
   http://bugs.python.org/issue1028reopened ocean-city
   patch

 Byte/string inconsistencies between different dbm modules11/21/08
   http://bugs.python.org/issue3799reopened brett.cannon
   patch, needs review

 type of UserList instance returns class instead of instance  11/14/08
 CLOSED http://bugs.python.org/issue4326created  chafporte


 Patch: simplify complex constant assignment statements   11/14/08
   http://bugs.python.org/issue4327created  novalis_dt
   patch

 à in ufoo raises a misleading error 11/15/08
   http://bugs.python.org/issue4328created  ezio.melotti


 base64 does not properly handle unicode strings  11/15/08
   http://bugs.python.org/issue4329created  mbecker


 wsgiref.validate doesn't accept arguments to readline11/16/08
 CLOSED http://bugs.python.org/issue4330created  ianb


 Can't use _functools.partial() created function as method11/16/08
   http://bugs.python.org/issue4331created  ssadler


 asyncore.file_dispatcher does not use dup()'ed fd11/17/08
 CLOSED http://bugs.python.org/issue4332created  christianbecke
   patch

 Reworked Dialog.py   11/17/08
   http://bugs.python.org/issue4333created  gpolo
   patch

 Mac Build Script is broken for 2.6 release   11/17/08
 CLOSED http://bugs.python.org/issue4334created  ngift


 inspect.getsourcelines ignores last line in module   11/17/08
   http://bugs.python.org/issue4335created  RafeSacks


 Fix performance issues in xmlrpclib  11/17/08
   http://bugs.python.org/issue4336created  krisvale
   patch, patch, easy

 Iteration over a map object with list()  11/17/08
 CLOSED http://bugs.python.org/issue4337created  jmfauth


 TypeError (bytes/str) in distutils command upload  11/17/08
 CLOSED http://bugs.python.org/issue4338created  hagen
   patch

 Fix set-like dictview doc11/17/08
 CLOSED http://bugs.python.org/issue4339created  tjreedy


 xmlrpc.client - default 'SlowParser' not defined 11/17/08
   http://bugs.python.org/issue4340created  mwatkins


 Update __hash__ doc  11/17/08
 CLOSED http://bugs.python.org/issue4341created  tjreedy


 (Tkinter) Please backport these  11/18/08
   http://bugs.python.org/issue4342created  gpolo


 New function in Tkinter.py: setup_master 11/18/08
   http://bugs.python.org/issue4343created  gpolo
   patch

 crash upon launch11/18/08
 CLOSED http://bugs.python.org/issue4344created  source.mod


 Implement nb_nonzero for PyTclObject 11/18/08
   http://bugs.python.org/issue4345created  gpolo
   patch

 PyObject_CallMethod changes the exception message already set by 11/18/08
   http://bugs.python.org/issue4346created  gpolo
   patch

 Dependencies of graminit.h are not rebuilt when the file is rege 11/18/08
   http://bugs.python.org/issue4347created  thomas.lee
   patch

 bytearray methods returning self 11/18/08
 CLOSED http://bugs.python.org/issue4348created  DinoV
   patch, needs review

 sys.path includes extraneous junk11/18/08
 CLOSED http://bugs.python.org/issue4349created  exarkun
   patch, needs review

 Remove dead code from Tkinter.py 11/19/08
   

Re: [Python-Dev] Summary of Python tracker Issues

[Jeremy Hylton]

On Mon, Nov 24, 2008 at 12:54 PM, Brett Cannon [EMAIL PROTECTED] wrote:
 On Mon, Nov 24, 2008 at 08:58, Jeremy Hylton [EMAIL PROTECTED] wrote:
 I wanted to ask a policy question on the bug tracker.  What are we
 doing with bugs filed against Python 2.4?
 This bug http://bugs.python.org/issue1208304 reports a fd leak in
 Python 2.4, which doesn't exist in the head.  Since Python 2.4 is in
 security-fix only mode, is it fair to close this with a won't fix?


 I think so.

 A meta-question:  Is there a document that has any tips on how to
 handle bug reports?  It might be helpful to have a list of hints or
 policy decisions to help people decide what to do with bugs.

 It's coming. I just have not gotten around to it yet. I plan to
 outline the basic steps in the life of an issue and that includes
 closing an issue and the various reasons this can happen.

If you put up skeleton doc, I can add a note to this effect.

Jeremy


 -Brett



 Jeremy

 On Fri, Nov 21, 2008 at 12:06 PM, Python tracker [EMAIL PROTECTED] wrote:

 ACTIVITY SUMMARY (11/14/08 - 11/21/08)
 Python tracker at http://bugs.python.org/

 To view or respond to any of the issues listed below, click on the issue
 number.  Do NOT respond to this message.


  2194 open (+35) / 14007 closed (+18) / 16201 total (+53)

 Open issues with patches:   728

 Average duration of open issues: 712 days.
 Median duration of open issues: 2043 days.

 Open Issues Breakdown
   open  2177 (+35)
 pending17 ( +0)

 Issues Created Or Reopened (56)
 ___

 Tkinter binding involving Control-spacebar raises unicode error  11/18/08
   http://bugs.python.org/issue1028reopened ocean-city
   patch

 Byte/string inconsistencies between different dbm modules11/21/08
   http://bugs.python.org/issue3799reopened brett.cannon
   patch, needs review

 type of UserList instance returns class instead of instance  11/14/08
 CLOSED http://bugs.python.org/issue4326created  chafporte


 Patch: simplify complex constant assignment statements   11/14/08
   http://bugs.python.org/issue4327created  novalis_dt
   patch

 à in ufoo raises a misleading error 11/15/08
   http://bugs.python.org/issue4328created  ezio.melotti


 base64 does not properly handle unicode strings  11/15/08
   http://bugs.python.org/issue4329created  mbecker


 wsgiref.validate doesn't accept arguments to readline11/16/08
 CLOSED http://bugs.python.org/issue4330created  ianb


 Can't use _functools.partial() created function as method11/16/08
   http://bugs.python.org/issue4331created  ssadler


 asyncore.file_dispatcher does not use dup()'ed fd11/17/08
 CLOSED http://bugs.python.org/issue4332created  christianbecke
   patch

 Reworked Dialog.py   11/17/08
   http://bugs.python.org/issue4333created  gpolo
   patch

 Mac Build Script is broken for 2.6 release   11/17/08
 CLOSED http://bugs.python.org/issue4334created  ngift


 inspect.getsourcelines ignores last line in module   11/17/08
   http://bugs.python.org/issue4335created  RafeSacks


 Fix performance issues in xmlrpclib  11/17/08
   http://bugs.python.org/issue4336created  krisvale
   patch, patch, easy

 Iteration over a map object with list()  11/17/08
 CLOSED http://bugs.python.org/issue4337created  jmfauth


 TypeError (bytes/str) in distutils command upload  11/17/08
 CLOSED http://bugs.python.org/issue4338created  hagen
   patch

 Fix set-like dictview doc11/17/08
 CLOSED http://bugs.python.org/issue4339created  tjreedy


 xmlrpc.client - default 'SlowParser' not defined 11/17/08
   http://bugs.python.org/issue4340created  mwatkins


 Update __hash__ doc  11/17/08
 CLOSED http://bugs.python.org/issue4341created  tjreedy


 (Tkinter) Please backport these  11/18/08
   http://bugs.python.org/issue4342created  gpolo


 New function in Tkinter.py: setup_master 11/18/08
   http://bugs.python.org/issue4343created  gpolo
   patch

 crash upon launch11/18/08
 CLOSED http://bugs.python.org/issue4344created  source.mod


 Implement nb_nonzero for PyTclObject 11/18/08
   http://bugs.python.org/issue4345created  gpolo
   patch

 PyObject_CallMethod changes the exception message already set by 11/18/08
   http://bugs.python.org/issue4346created  gpolo
   patch

 Dependencies of graminit.h are not rebuilt when the file is rege 11/18/08
   http://bugs.python.org/issue4347created

Re: [Python-Dev] [Python-checkins] buildbot failure in sparc Debian 3.0

[Jeremy Hylton]

Does anyone have a clue about why this test fails only on this
platform?  The test is question is verifying that URLError gets
raised.  From the traceback, it appears that there is an uncaught
exception (URLError) but it fails in an assertRaises() check for
URLError.  That doesn't make much sense unless the variable URLError
refers to different objects, but both modules use from urllib.error
import URLError.  And, of course, the test works fine on other
platforms.

Jeremy

On Wed, Jul 2, 2008 at 4:23 PM,  [EMAIL PROTECTED] wrote:
 The Buildbot has detected a new failure of sparc Debian 3.0.
 Full details are available at:
  http://www.python.org/dev/buildbot/all/sparc%20Debian%203.0/builds/330

 Buildbot URL: http://www.python.org/dev/buildbot/all/

 Buildslave for this Build: klose-debian-sparc

 Build Reason:
 Build Source Stamp: [branch branches/py3k] HEAD
 Blamelist: benjamin.peterson

 BUILD FAILED: failed test

 Excerpt from the test logfile:
 1 test failed:
test_urllib2

 ==
 ERROR: test_badly_named_methods (test.test_urllib2.OpenerDirectorTests)
 --

 Traceback (most recent call last):
  File 
 /home/pybot/buildarea-sid/3.0.klose-debian-sparc/build/Lib/test/test_urllib2.py,
  line 408, in test_badly_named_methods
self.assertRaises(URLError, o.open, scheme+://example.com/)
  File 
 /home/pybot/buildarea-sid/3.0.klose-debian-sparc/build/Lib/unittest.py, 
 line 311, in failUnlessRaises
callableObj(*args, **kwargs)
  File 
 /home/pybot/buildarea-sid/3.0.klose-debian-sparc/build/Lib/urllib/request.py,
  line 356, in open
response = self._open(req, data)
  File 
 /home/pybot/buildarea-sid/3.0.klose-debian-sparc/build/Lib/urllib/request.py,
  line 379, in _open
'unknown_open', req)
  File 
 /home/pybot/buildarea-sid/3.0.klose-debian-sparc/build/Lib/urllib/request.py,
  line 334, in _call_chain
result = func(*args)
  File 
 /home/pybot/buildarea-sid/3.0.klose-debian-sparc/build/Lib/urllib/request.py,
  line 1102, in unknown_open
raise URLError('unknown url type: %s' % type)
 urllib.error.URLError: urlopen error unknown url type: do

 make: *** [buildbottest] Error 1

 sincerely,
  -The Buildbot

 ___
 Python-checkins mailing list
 [EMAIL PROTECTED]
 http://mail.python.org/mailman/listinfo/python-checkins

___
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] Trickery with moving urllib

[Jeremy Hylton]

On Sat, May 10, 2008 at 11:38 PM, Brett Cannon [EMAIL PROTECTED] wrote:
 There is going to be an issue with the current proposal for keeping
 around urllib. Since the package is to be named the same thing as the
 module, to handle the new name that means urllib.__init__ will need to
 gain the Py3K warning for the new name. But that doesn't quite work as
 the package's module will be imported automatically any time the
 module within the package is used.

 I see three solutions for dealing with this.

 1. Have stubs for the entire urllib API in urllib.__init__ that raise
 a DeprecationWarning either specifying the new name or saying the
 function/class is deprecated.

 2. Rename urllib to urllib.fetch or urllib.old_request to get people
 to move over to urllib.request (aka urllib2) at some point.

 3. Ditch urllib completely and have people move to urllib.request
 directly from 2.6 going into 3.0.

 I was a fan of 3 in the stdlib SIG, but MAL argued well for 2 since so
 much code uses urllib (although I have always wondered how many
 *really* use urllib and how many could easily just move over to
 urllib2). The current solution of keeping around urllib's classes was
 a compromise, but I had not thought out the transition yet (and Jeremy
 Hylton will be running into this as he has volunteered to handle
 this).

 What do people think we should do?

I am migrating all the stdlib code to use urllib2 APIs when possible.
It seems straightforward enough to keep the old urllib classes in
urllib.request, but change the standard API functions (urlopen,
urlretrieve) to use the urllib2 implementation.

We could probably have a big collection of deprecation warnings in the
urllib/__init__ without much trouble.  It doesn't have any code at
this point.

Jeremy


 -Brett
 ___
 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/jeremy%40alum.mit.edu

___
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] Optimization of Python ASTs: How should we deal with constant values?

[Jeremy Hylton]

On Thu, May 8, 2008 at 8:00 AM, Nick Coghlan [EMAIL PROTECTED] wrote:
 Jeremy Hylton wrote:

  On Wed, May 7, 2008 at 11:43 AM, Thomas Lee [EMAIL PROTECTED] wrote:
 
   Nick Coghlan wrote:
  
  
As Thomas mentions in a later message, making it possible to annotate
   
   nodes would permit Functions to be annotated as being a generator at the
 AST
   stage (currently it is left to the bytecode compiler's symtable
 generation
   pass to make that determination).
  
Although I guess an alternative solution to that would be to have
 separate
   
   AST nodes for Functions and Generators as well...
  
   
   
I've actually backtracked a little and gone back down the Const path
 again.
   I know this is the third time I've changed my mind, but it's primarily
   because annotations tend to get a little clunky (or my implementation
 was,
   at least). Using Const nodes feels a lot more natural inside the
 optimizer.
   I think it's going to stick, at least in the short term.
  
Rather than separate FunctionDef and GeneratorDef nodes, I think a new
 bool
   attribute (is_generator?) on FunctionDef should do the job nicely.
 Further,
   I'm thinking we can move the generator detection code from the
 symtable
   into Python/ast.c so the generator/function information is available to
 the
   optimizer.
  
 
  Does the optimizer run after the symtable?  I'd expect the symbol
  table information to be essential for almost all analysis, so it
  should be fine to wait until that pass to mark the generators.
 

  There are a lot of micro-optimisations that are actually context
 independent, so moving them before the symtable pass should be quite
 feasible - e.g. replacing return None with return, stripping dead code
 after a return statement, changing a if not statement into an if
 statement with the two suites reversed, changing (1, 2, 3) into a stored
 constant, folding 1 + 2 into the constant 3.

  I believe the goal is to see how many of the current bytecode optimisations
 can actually be brought forward to the AST generation stage, rather than
 waiting until after the bytecode symtable calculation and compilation
 passes.

  The current structure goes:

  tokenisation-AST construction-symtable construction-bytecode
 compilation-bytecode optimisation

  My understanding of what Thomas is trying to do is to make it look more
 like this:

  tokenisation-AST construction-AST optimisation-symtable
 construction-bytecode compilation

  There may still be a direct bytecode optimisation step left at the end if
 it turns out something relies on information that isn't worked out until the
 symtable construction pass (and that can't easily be worked out earlier,
 such as adding an 'is_generator' flag to the FunctionDef AST node).

The symbol table pass is not important for deciding where to place the
optimizations.  Either the optimization operates on the AST itself, in
which case it needs to run before bytecode compilation or it operators
on the lowered bytecode representation, in which case it needs to run
after bytecode compilation.  Since the symbol table passes doesn't
change the representation, you ought to be able to put the
optimizations before or after it.

But I haven't looked closely at the actual code, so maybe I'm missing something.

Jeremy




  Cheers,
  Nick.

  --
  Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
  ---
 http://www.boredomandlaziness.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] Optimization of Python ASTs: How should we deal with constant values?

[Jeremy Hylton]

On Wed, May 7, 2008 at 11:43 AM, Thomas Lee [EMAIL PROTECTED] wrote:
 Nick Coghlan wrote:

 
  As Thomas mentions in a later message, making it possible to annotate
 nodes would permit Functions to be annotated as being a generator at the AST
 stage (currently it is left to the bytecode compiler's symtable generation
 pass to make that determination).
 
  Although I guess an alternative solution to that would be to have separate
 AST nodes for Functions and Generators as well...
 
 
  I've actually backtracked a little and gone back down the Const path again.
 I know this is the third time I've changed my mind, but it's primarily
 because annotations tend to get a little clunky (or my implementation was,
 at least). Using Const nodes feels a lot more natural inside the optimizer.
 I think it's going to stick, at least in the short term.

  Rather than separate FunctionDef and GeneratorDef nodes, I think a new bool
 attribute (is_generator?) on FunctionDef should do the job nicely. Further,
 I'm thinking we can move the generator detection code from the symtable
 into Python/ast.c so the generator/function information is available to the
 optimizer.

Does the optimizer run after the symtable?  I'd expect the symbol
table information to be essential for almost all analysis, so it
should be fine to wait until that pass to mark the generators.

Jeremy

  This is made a little tricky by the absence of the contextual information
 available that is normally available when flagging generators in the
 symtable. When generating AST nodes for a suite, we know nothing about the
 parent node in which the suite resides. Still, it might be doable. If this
 winds up being ugly, we might need to fall back to the original plan of a
 separate pass over function bodies to detect yield expressions.

  I'll look into all this tomorrow night, along with any other crazy
 suggestions. For now I need to sleep a few hours. :)

  Thanks for the feedback, it's much appreciated.

  Cheers,
  T


___
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] AST Optimization: Branch Elimination in Generator Functions

[Jeremy Hylton]

I'm not sure I understand the problem exactly.  If we have one pass
converting the concrete syntax to the AST, we can mark functions as
generators as part of that pass.  In a later pass, you can remove the
unreachable code.

Jeremy

On Sat, May 3, 2008 at 12:51 AM, Thomas Lee [EMAIL PROTECTED] wrote:
 The next problem that cropped up during the implementation of the AST code
 optimizer is related to branch elimination and the elimination of any code
 after a return.

  Within a FunctionDef node, we would (ideally) like to blow away If nodes
 with a constant - but false - test expression. e.g.:

  def foo():
  if False:
   # ... stuff ...

  For most functions, this will cause no problems and the code will behave as
 expected. However, if the eliminated branch contains a yield expression,
 the function is actually a generator function - even if the yield expression
 can never be reached:

  def foo():
  if False:
   yield 5

  In addition to this, the following should also be treated as a generator
 even though we'd like to be able to get rid of all the code following the
 return statement:

  def foo():
  return
  yield 5

  Again, blowing away the yield results in a normal function instead of a
 generator. Not what we want: we need to preserve the generator semantics.

  Upon revisiting this, it's actually made me reconsider the use of a Const
 node for the earlier problem relating to arbitrary constants. We may be
 better off with annotations after all ... then we could mark FunctionDef
 nodes as being generators at the AST level to force the compiler to produce
 code for a generator, but eliminate the branches anyway.

  The other alternative I can think of is injecting a yield node somewhere
 unreachable and ensuring it doesn't get optimized away, but this seems
 pretty hacky in comparison.

  Any other ideas?

  Cheers,
  Tom
  ___
  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/jeremy%40alum.mit.edu

___
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] GC Changes

[Jeremy Hylton]

On 10/1/07, Justin Tulloss [EMAIL PROTECTED] wrote:
 Hello,

 I've been doing some tests on removing the GIL, and it's becoming clear that
 some basic changes to the garbage collector may be needed in order for this
 to happen efficiently. Reference counting as it stands today is not very
 scalable.

 I've been looking into a few options, and I'm leaning towards the
 implementing IBMs recycler GC (
 http://www.research.ibm.com/people/d/dfb/recycler-publications.html
 ) since it is very similar to what is in place now from the users'
 perspective. However, I haven't been around the list long enough to really
 understand the feeling in the community on GC in the future of the
 interpreter. It seems that a full GC might have a lot of benefits in terms
 of performance and scalability, and I think that the current gc module is of
 the mark-and-sweep variety. Is the trend going to be to move away from
 reference counting and towards the mark-and-sweep implementation that
 currently exists, or is reference counting a firmly ingrained tradition?

 On a more immediately relevant note, I'm not certain I understand the full
 extent of the gc module. From what I've read, it sounds like it's fairly
 close to a fully functional GC, yet it seems to exist only as a
 cycle-detecting backup to the reference counting mechanism. Would somebody
 care to give me a brief overview on how the current gc module interacts with
 the interpreter, or point me to a place where that is done? Why isn't the
 mark-and-sweep mechanism used for all memory management?

There are probably lots of interesting things to say about the gc
cycle collector, but I'll just pick a few things that seem relevant.
First off, the gc doesn't have a root set.  It traces all the
container objects, subtracting known references from the refcount, and
is left with a root set, i.e. those objects that have some references
that can't be accounted for among the known container objects.  (see
update_refs and substract_refs)  In the end, we make three traversals
of the heap to detect the objects that appear to be unreachable.
(move_unreachable is the third.)

The cycle detection relies on having the reference counts correct, so
it doesn't really represent a move away from refcounting.

I skipped the generations.  The GC divides the heap into three
generations and tends to focus on the youngest generation.  So that
limits the portion of the heap that is scanned, but I don't understand
the magnitude of that effect in practice.

The current collector works in collaboration with ref counting.  In
particular, refcounting probably handles the majority of
deallocations.  If the cycle detection system were responsible for all
deallocations, the gc module would have a lot more work to do.

I do think it would be interesting to experiment with the recycler
approach, but I think it would take a lot of work to do a decent
experiment.  But please give it a shot!

Jeremy
___
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] HTTP responses and errors

[Jeremy Hylton]

On 4/10/07, Facundo Batista [EMAIL PROTECTED] wrote:
 Facundo Batista wrote:

  Martin v. Löwis wrote:
  ...
 
  think it should treat all 2xx responses as success. Callers can
  then still check the response code themselves if they need to.
 
  The same I think. If nobody has a conflic with this decission, I'll fix
  this.

 Nobody raised any objection, I'll fix this these days.

+1

Jeremy
___
Python-Dev mailing list
[EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Proposal to revert r54204 (splitext change)

[Jeremy Hylton]

On 3/15/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
 On 05:51 pm, [EMAIL PROTECTED] wrote:
 At 07:45 AM 3/15/2007 +0100, Martin v. Löwis wrote:
 I apparently took the same position that you now take back then,
 whereas I'm now leaning towards (or going beyond) the position
 Tim had back then, who wrote BTW, if it *weren't* for the code breakage,
 I'd be in favor of doing this.
 
 If it weren't for the code breakage, I'd be in favor too.  That's not the
 point.
 
 The point is that how can Python be stable as a language if precedents can
 be reversed without a migration plan, just because somebody changes their
 mind?  In another five years, will you change your mind again, and decide
 to put this back the way it was?

 Hear, hear.  Python is _not_ stable as a language.  I have Java programs
 that I wrote almost ten years ago which still run perfectly on the latest
 runtime.  There is python software I wrote two years ago which doesn't work
 right on 2.5, and some of the Python stuff contemporary with that Java code
 won't even import.

I think the problem has less to do with bug fixing than with lack of
any clear specifications or documentation about what developers can
depend on.You could probably make a case that any change that
doesn't fix a crash bug is likely to cause some particular program to
behave differently.

Take bug 1504333 which lead to a change in sgmllib behavior for angle
brackets in quoted attribute values.  Did the sgmllib documentation
explain that the fixed behavior was incorrect?  Might a programmer
working with sgmllib have written code that depended on this bug?  Do
you object to this bug fix?

For many of these bugs, some people will have written code against the
documentation and some people against the implementation or behavior.
(In this case, the documentation is vague or conflicting.)  I don't
think I know how to balance the important of these two classes of
users.  Some code is going to break the first time they run into the
under-specific edge case, some code is going to break when the
specification and implementation are clarified.  You have to weigh
which you think is more likely and which will benefit users the most.

I think everyone wants to do the right thing by Python's users, but
it's not clear what that right thing is.

 Speaking as a business person, that seems to me... unwise.  When I found
 out that this change had been checked in despite all the opposition, my gut
 reaction was, I guess I can't rely on Python any more, despite 10 years
 of working with it, developing open source software with it, and
 contributing to its development.  Because from a *business* perspective,
 this sort of flip-flopping means that moving from one minor Python
 version to another is potentially *very* costly.

 And indeed it is.  Python's advantages in terms of rapidity of development
 have, thus far, made up the difference for me, but it is threatening to
 become a close thing.  This is a severe problem and something needs to be
 done about it.

Could you point out a few such programs that people on python-dev can
look at?  I think it would be useful to gather some data about the
kind of migration pains real users are having.  I believe Martin and
others are trying to do the right thing.  Real data is more likely to
convince them than passionate arguments on python-dev.

 But as you are so fond of pointing out, there is no many people.  There
 are only individual people.  That a majority want it one way, means that
 there is a minority who want it another.  If next year, it becomes more
 popular to have it the other way, will we switch again?  If a majority of
 people want braces and required type declarations, will we add them?

 And, in fact, there is not even a majority.  There is a *perception* of a
 majority.  There isn't even a *perception* of a majority of Python users,
 but a perception of a majority of python-dev readers, who are almost by
 definition less risk-averse when it comes to language change than anyone
 else!

I think you missed the point here.  The hypothetical question was not
about any particular majority, but rather that regardless of which
group you poll, the majority decision may not be the right one.  Even
a majority of Twised users :-).

Jeremy

 If we actually care about majorities, let's set up a voting application and
 allow Python users to vote on each and every feature, and publicize it each
 time such a debate comes up.  Here, I'll get it started:
 http://jyte.com/cl/python-should-have-a-strict-backward-compatibility-policy-to-guide-its-development

 According to that highly scientific study, at this point in time, Nobody
 disagrees :).  (One in favor, zero against.)

 ___
 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/jeremy%40alum.mit.edu

Re: [Python-Dev] locals(), closures, and IronPython...

[Jeremy Hylton]

On 3/5/07, Dino Viehland [EMAIL PROTECTED] wrote:
 Thanks Guido.  It might take some time (and someone may very well beat me to 
 it if they care a lot) but I'll see if we can get the PEP started.

Dino,

One of the questions I was puzzling over was what locals() should
return in a class scope.  It's confusing in CPython, because the same
dictionary is used to stored names that are destined to become class
attributes and names that are used to created closures for methods
with free variables.  The implementation was causing the latter names
to show up as class attributes when you called locals().

Terry is right that lifetime of variables is a key issue.  It would
probably be bad if all the local variables of a function were kept
alive because a nested function used locals().

One idea was discussed at PyCon was having a different representation
for an environment so that it would be easier to introspect on it but
still possible to pass the environment to exec.  One possibility is
just a third dictionary--globals, locals, nonlocals.  Another
possibility is an object where you can ask about the scope of each
variable but also extract a dictionary to pass to locals.

Jeremy


 -Original Message-
 From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Guido van 
 Rossum
 Sent: Monday, March 05, 2007 2:14 PM
 To: Dino Viehland
 Cc: python-dev@python.org
 Subject: Re: [Python-Dev] locals(), closures, and IronPython...

 Jeremy Hylton has been asking questions about this too at the sprint
 after PyCon. I'm tempted to accept that the exact behavior of locals()
 is implementation-defined (IOW undefined :-) as long as it includes
 the locals defined in the current scope; whether it also includes free
 variables could be debatable. I don't know too many good use cases for
 locals() apart from learning about the implementation I think this
 might be okay. Though a PEP might be in order to get agreement between
 users, developers and other implementation efforts (e.g. PyPy,
 Jython).

 On 3/5/07, Dino Viehland [EMAIL PROTECTED] wrote:
 
 
 
 
  def a():
 
  x = 4
 
  y = 2
 
  def b():
 
  print y, locals()
 
  print locals()
 
  b()
 
 
 
  a()
 
 
 
  in CPython prints:
 
 
 
  {'y': 2, 'x': 4, 'b': function b at 0x020726F0}
 
  2 {'y': 2}
 
 
 
  I'm wondering if it's intentional that these don't print dictionaries w/ the
  same contents or if it's more an accident of the implementation.   In other
  words would it be reasonable for IronPython to promote all of the locals of
  a into b's dictionary when both a and b call locals?
 
 
 
  We currently match CPython's behavior here - at least in what we display
  although possibly not in the lifetimes of objects.  We're considering an
  internal change which might alter the behavior here though and end up
  displaying all the members.
 
 
 
 
  ___
  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/guido%40python.org
 
 


 --
 --Guido van Rossum (home page: http://www.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/jeremy%40alum.mit.edu

___
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] Encouraging developers

[Jeremy Hylton]

On 3/6/07, Georg Brandl [EMAIL PROTECTED] wrote:
 Raymond Hettinger schrieb:
  [Phil Thompson]
  I think a lot of people care, but many can't
  do anything about because the barrier to entry is too great.
 
  Do you mean commit priviledges?  ISTM, those tend to be
  handed out readily to people who assert that they have good use for them.
  Ask the Georg-bot how readily he was accepted and coached.  IMO,
  his acceptance was a model that all open source projects should aspire to.

 Indeed. For me, it wasn't hard to get tracker rights. I reviewed some 
 patches,
 commented on bugs, posted suggestions to python-dev etc. When I asked about
 tracker rights on python-dev, they were given to me.
 Then, it wasn't hard to get commit rights. I contributed some stuff, and
 after a while I asked about commit rights on python-dev, and they were given
 to me on condition that I still let a core dev review inteded changes.

 As far as I recall, there has been nearly no one who asked for commit rights
 recently, so why complain that the entry barrier is too great? Surely you
 cannot expect python-dev to got out and say would you like to have commit
 privileges?...

You can ask whether we should have a plan for increasing the number of
developers, actively seeking out new developers, and mentoring people
who express interest.  Would the code be better if we had more good
developers working on it?  Would we get more bugs fixed and patches
closed?  If so, it wouldn't hurt to have some deliberate strategy for
bringing new developers in.  I can easily imagine someone spending a
lot of time mentoring and a little time coding, but having a bigger
impact that someone who only wrote code.

Jeremy
___
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] dinner at Standard in Dallas

[Jeremy Hylton]

I'm organizing a trip to Standard in downtown Dallas for dinner
tonight (Sunday night).  It's about a 10 minute cab ride to Standard.
We can share cabs and get there without too much trouble.  The
restaurant is on the expensive side.  I'm thinking we should leave
from the hotal around 6:30pm.

http://www.standarddallas.com/
http://restaurants.dallasobserver.com/search/restaurants.php?oid=27399

A large group of us went for dinner last year and had a great time.
The food was excellent, short ribs and mashed potatoes with truffles
stand out in my mind.  They also serve a tangerita cocktail--margerita
made with Tang--that was memorable.

Let me know if you'd like to come and I'll make reservations and
arrange for cabs.

Jeremy

[Apologies if you get two copies of this message.  The first one looks
like it got lost or stuck.]
___
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] dinner at Standard in Dallas

[Jeremy Hylton]

I'm organizing a trip to Standard in downtown Dallas for dinner
tonight (Sunday night).  It's about a 10 minute cab ride to Standard.
We can share cabs and get there without too much trouble.  The
restaurant is on the expensive side.  I'm thinking we should leave
from the hotal around 6:30pm.

http://www.standarddallas.com/
http://restaurants.dallasobserver.com/search/restaurants.php?oid=27399

A large group of us went for dinner last year and had a great time.
The food was excellent, short ribs and mashed potatoes with truffles
stand out in my mind.  They also serve a tangerita cocktail--margerita
made with Tang--that was memorable.

Let me know if you'd like to come and I'll make reservations and
arrange for cabs.

Jeremy
___
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] Renaming Include/object.h

[Jeremy Hylton]

On 1/3/07, Martin v. Löwis [EMAIL PROTECTED] wrote:
 In #1626545, Anton Tropashko requests that object.h should be
 renamed, because it causes conflicts with other software.

 I would like to comply with this requests for 2.6, assuming there
 shouldn't be many problems with existing software as object.h
 shouldn't be included directly, anyway.

I like the idea of renaming the header files, but I expect there is a
lot more opportunity for breaking code that you estimate.  I did a
search on google.com/codesearch and found seven external packages that
include Python.h and object.h (before I gave up).

I assume we expect people won't include it, because it is also
included in object.h.  But they do it.  Is there documentation that
says you shouldn't import it?

Jeremy


 What do you think?

 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/jeremy%40alum.mit.edu

___
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] safety of Py_CLEAR and self

[Jeremy Hylton]

I was wondering today how I could convince myself that a sequence of
Py_CLEAR() calls in a tp_clear function was safe.  Take for example a
really trivial sequence of code on frame_clear():

Py_CLEAR(f-f_exc_type);
Py_CLEAR(f-f_exc_value);
Py_CLEAR(f-f_exc_traceback);
Py_CLEAR(f-f_trace);

We use Py_CLEAR() so that multiple calls to frame_clear() are safe.
The first time this runs it sets exc_type to NULL before calling
DECREF.  This guarantees that a subsequent frame_clear() or
frame_dealloc() won't attempt to DECREF it a second time.  I think I
understand why that's desireable and why it works.  The primary risk
is that via DECREF we may execute an arbitrary amount of Python code
via weakref callbacks, finalizers, and code in other threads that gets
resumed while the callbacks and finalizers are running.

My question, specifically, then: Why it is safe to assume that f
doesn't point to trash after a particular call to Py_CLEAR()?  Any
particular call to Py_CLEAR() could break the cycle that the object is
involved in an lead to a call to frame_dealloc().  The frame could get
returned to an obmalloc pool, returned to the OS, or just re-used by
another object before we get back to Py_CLEAR().  It seems like such
behavior would be exceedingly unlikely, but I can't convince myself
that it is impossible.  Which is it: improbable or impossible?  If it
is only improbable, should we figure out how to write code that is
safe against such an improbable event?

Jeremy
___
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] safety of Py_CLEAR and self

[Jeremy Hylton]

On 2/12/07, Guido van Rossum [EMAIL PROTECTED] wrote:
 Looking for where tp_clear() is being called, the only caller is line
 713 in gmodule.c, which explicitly surrounds the call with an
 INCREF/DECREF pair. Perhaps that's the clue you're looking for?

Yes, of course.  The INCREF guarantees that the object can't be
collected until the tp_clear() returns.  Thanks.

Jeremy


 --Guido

 On 2/12/07, Jeremy Hylton [EMAIL PROTECTED] wrote:
  I was wondering today how I could convince myself that a sequence of
  Py_CLEAR() calls in a tp_clear function was safe.  Take for example a
  really trivial sequence of code on frame_clear():
 
  Py_CLEAR(f-f_exc_type);
  Py_CLEAR(f-f_exc_value);
  Py_CLEAR(f-f_exc_traceback);
  Py_CLEAR(f-f_trace);
 
  We use Py_CLEAR() so that multiple calls to frame_clear() are safe.
  The first time this runs it sets exc_type to NULL before calling
  DECREF.  This guarantees that a subsequent frame_clear() or
  frame_dealloc() won't attempt to DECREF it a second time.  I think I
  understand why that's desireable and why it works.  The primary risk
  is that via DECREF we may execute an arbitrary amount of Python code
  via weakref callbacks, finalizers, and code in other threads that gets
  resumed while the callbacks and finalizers are running.
 
  My question, specifically, then: Why it is safe to assume that f
  doesn't point to trash after a particular call to Py_CLEAR()?  Any
  particular call to Py_CLEAR() could break the cycle that the object is
  involved in an lead to a call to frame_dealloc().  The frame could get
  returned to an obmalloc pool, returned to the OS, or just re-used by
  another object before we get back to Py_CLEAR().  It seems like such
  behavior would be exceedingly unlikely, but I can't convince myself
  that it is impossible.  Which is it: improbable or impossible?  If it
  is only improbable, should we figure out how to write code that is
  safe against such an improbable event?
 
  Jeremy
  ___
  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/guido%40python.org
 


 --
 --Guido van Rossum (home page: http://www.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

Re: [Python-Dev] classes and cell variables question

[Jeremy Hylton]

On 12/19/06, tomer filiba [EMAIL PROTECTED] wrote:
 to my understanding of the object model, the code of snippet 1
 and snippet 2 should be equivalent. a class is just a special function
 that returns its locals automatically and passes them to the metaclass
 constructor:

 --- snippet 1 ---
 class foo(object):
 x = 5
 def f(self):
 print f, x

 --- snippet 2 ---
 def bar():
 x = 5
 def g(self):
 print g, x
 return locals()
 barcls = type(barcls, (object,), bar())

 but there's one big difference. classes don't create cell variables
 to hold bound external variables. the bar version works, because
 x is a bound cell variable, but the foo version fails, as it attempts
 to access x as a global.

Others have explained the rationale for this design choice, and the
PEP is a good source for what we were thinking at the time.

I thought it was worth adding that a) class variables can never be
access as free variables, as your example foo() shows, and b) you
could access a variable bound in a function scope in a method.
Example of b):

def spam():
  x = 5  # provides the binding for the free variable x in methods of eggs
  class eggs(object):
x = 6  # irrelevant for purposes of resolving the free variable in
the method spam
def spam(self):  # can't have too much spam
  return x
  return eggs

spam()().spam() should return 5.

Jeremy


 . barcls().g()
 g 5

 . foo().f()
 f
 Traceback (most recent call last):
   File stdin, line 1, in module
   File stdin, line 4, in f
 NameError: global name 'x' is not defined

 for reference, i attached the code of all four functions below.

 my question is, how come classes don't create cell variables, like
 normal functions? was this done on purpose? does it have to
 do with inheritance? if so, what's wrong with my bar version?


 [1]
 # code of class foo
 
 #  2   0 LOAD_NAME0 (__name__)
 #  3 STORE_NAME   1 (__module__)
 #  3   6 LOAD_CONST   0 (5)
 #  9 STORE_NAME   2 (x)
 #
 #  4  12 LOAD_CONST   1 (code object f at
 009E5608, file stdin, line 4)
 # 15 MAKE_FUNCTION0
 # 18 STORE_NAME   3 (f)
 # 21 LOAD_LOCALS
 # 22 RETURN_VALUE

 [2]
 # code of foo.f:
 
 #  5   0 LOAD_CONST   1 ('f')
 #  3 PRINT_ITEM
 #  4 LOAD_GLOBAL  0 (x)
 #  7 PRINT_ITEM
 #  8 PRINT_NEWLINE
 #  9 LOAD_CONST   0 (None)
 # 12 RETURN_VALUE

 [3]
 # code of bar:
 
 #  2   0 LOAD_CONST   1 (5)
 #  3 STORE_DEREF  0 (x)
 #
 #  3   6 LOAD_CLOSURE 0 (x)
 #  9 BUILD_TUPLE  1
 # 12 LOAD_CONST   2 (code object g at
 009F6698, file stdin, line 3)
 # 15 MAKE_CLOSURE 0
 # 18 STORE_FAST   0 (g)
 #
 #  5  21 LOAD_GLOBAL  0 (locals)
 # 24 CALL_FUNCTION0
 # 27 RETURN_VALUE

 [4]
 # code of bar.g:
 
 #  4   0 LOAD_CONST   1 ('g')
 #  3 PRINT_ITEM
 #  4 LOAD_DEREF   0 (x)
 #  7 PRINT_ITEM
 #  8 PRINT_NEWLINE
 #  9 LOAD_CONST   0 (None)
 # 12 RETURN_VALUE
 ___
 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/jeremy%40alum.mit.edu

___
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 315 - do while

[Jeremy Hylton]

On 10/4/06, Guido van Rossum [EMAIL PROTECTED] wrote:
 You are all wasting your time on this. It won't go in.

+1 from me.  Should you mark PEP 315 as rejected?

Jeremy


 --
 --Guido van Rossum (home page: http://www.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/jeremy%40alum.mit.edu

___
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] AST structure and maintenance branches

[Jeremy Hylton]

On 9/23/06, Anthony Baxter [EMAIL PROTECTED] wrote:
 I'd like to propose that the AST format returned by passing PyCF_ONLY_AST to
 compile() get the same guarantee in maintenance branches as the bytecode
 format - that is, unless it's absolutely necessary, we'll keep it the same.
 Otherwise anyone trying to write tools to manipulate the AST is in for a
 massive world of hurt.

 Anyone have any problems with this, or can it be added to PEP 6?

It's possible we should poll developers of other Python
implementations and find out if anyone has objections to supporting
this AST format.  But in principle, it sounds like a good idea to me.

Jeremy
___
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] AST structure and maintenance branches

[Jeremy Hylton]

On 9/28/06, Anthony Baxter [EMAIL PROTECTED] wrote:
 On Friday 29 September 2006 00:30, Jeremy Hylton wrote:
  On 9/23/06, Anthony Baxter [EMAIL PROTECTED] wrote:
   I'd like to propose that the AST format returned by passing PyCF_ONLY_AST
   to compile() get the same guarantee in maintenance branches as the
   bytecode format - that is, unless it's absolutely necessary, we'll keep
   it the same. Otherwise anyone trying to write tools to manipulate the AST
   is in for a massive world of hurt.
  
   Anyone have any problems with this, or can it be added to PEP 6?
 
  It's possible we should poll developers of other Python
  implementations and find out if anyone has objections to supporting
  this AST format.  But in principle, it sounds like a good idea to me.

 I think it's extremely likely that the AST format will change over time -
 with major releases. I'd just like to guarantee that we won't mess with it
 other than that.

Good point.  I'm fine with the change, then.

Jeremy
___
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] Python sprint in NY and CA, Aug. 21-24

[Jeremy Hylton]

I'd like to repeat my invitation to spend a week at Google in
California or New York for a Python sprint.  We are hosting sprints at
our offices in Mountain View and New York City the week of Aug. 21,
Monday through Thursday.

We're planning to work broadly on Python 2.6 and Python 3000.  If
you're interested in the core implementation, the standard library,
the build process, or documentation, they're all in scope.  Working on
a test process using large community projects like Twisted and Zope
would be a great activity, too.

There's a wiki page with some more details:
 http://wiki.python.org/moin/GoogleSprint

Feel free to follow up with Neal or me if you have questions.

Jeremy
___
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] Community buildbots (was Re: User's complaints)

[Jeremy Hylton]

On 7/14/06, Anthony Baxter [EMAIL PROTECTED] wrote:
 On Friday 14 July 2006 16:39, Neal Norwitz wrote:
  Remember I also tried to push for more features to go in early?
  That would have given more time for external testing.  Still
  features are coming in.  Python developers weren't happy about
  having to get things in earlier.  I don't see a practical way to
  implement what you propose (see Anthony's comments).

 Following up on this point:
 Given the number of just-this-one-more-thing-please we've _already_
 had since the b1 feature freeze, do you really except that 90 days of
 feature freeze is feasible? And if there's not going to be a feature
 freeze, there's hardly any point to people doing testing until there
 _is_ a feature freeze, is there? Oh, great, my code works with 2.5b1.
 Oops. 2.5b9 added a new feature that broke my code, but I didn't test
 with that.

Maybe the basic question is right, but the emphasis needs to be
changed.  If we had a rule that said the final release was 90 days
after the last submission that wasn't to fix a regression, we'd ask
Is this feature important enough to warrant delaying the release
until three months from now?  I'm not sure what I think, but it
doesn't seem like an implausible policy.

Jeremy


 Anthony
 --
 Anthony Baxter [EMAIL PROTECTED]
 It's never too late to have a happy childhood.
 ___
 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/jeremy%40alum.mit.edu

___
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] Community buildbots (was Re: User's complaints)

[Jeremy Hylton]

On 7/14/06, Nick Coghlan [EMAIL PROTECTED] wrote:
 Anthony Baxter wrote:
  On Friday 14 July 2006 16:39, Neal Norwitz wrote:
  Remember I also tried to push for more features to go in early?
  That would have given more time for external testing.  Still
  features are coming in.  Python developers weren't happy about
  having to get things in earlier.  I don't see a practical way to
  implement what you propose (see Anthony's comments).
 
  Following up on this point:
  Given the number of just-this-one-more-thing-please we've _already_
  had since the b1 feature freeze, do you really except that 90 days of
  feature freeze is feasible? And if there's not going to be a feature
  freeze, there's hardly any point to people doing testing until there
  _is_ a feature freeze, is there? Oh, great, my code works with 2.5b1.
  Oops. 2.5b9 added a new feature that broke my code, but I didn't test
  with that.

 I think this is where release candidates can come into their own - the beta's
 can flush out the just-one-more-thing pleases, the maintenance branch is
 forked for rc1, and then any changes on the branch are purely to fix 
 regressions.

 As far as the idea of a suite of buildbots running the unit tests of large
 Python applications against the current SVN trunk goes, one problem is that
 failures in those buildbots will come from two sources:
- Python itself fails (broken checkin)
- the application unit tests fail (backwards incompatibility)

 To weed out the false alarms, the slaves will need to be set up to run the
 Python unit tests first and then the application unit tests only if the Python
 test run is successful.

 When the slave suffers a real failure due to a backwards incompatibility, it
 will take a developer of the application to figure out what it was that broke
 the application's tests.

 So while I think it's a great idea, I also think it will need significant
 support from the application developers in debugging any buildbot failures to
 really make it work.

These buildbots should run the tests from stable, released versions of
external packages, assuming that those packages don't ship releases
with failing tests.  If you ran the test suite for a Zope release and
had a test failure, I think there would be a reasonable expectation
that it was a Python bug.

I'd definitely avoiding mixing a development version of Python and a
development version of the test software in the automated build
environment.

Jeremy


 Cheers,
 Nick.

 --
 Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
 ---
  http://www.boredomandlaziness.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/jeremy%40alum.mit.edu

___
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] Explicit Lexical Scoping (pre-PEP?)

[Jeremy Hylton]

On 7/12/06, Fredrik Lundh [EMAIL PROTECTED] wrote:
 Boris Borcic wrote:

  note that most examples of this type already work, if the target type is
  mutable, and implement the right operations:
 
def counter(num):
num = mutable_int(num)
def inc():
num += 1
return num
return inc
 
  I agree with you (and argued it in scopes vs augmented assignment vs sets
  recently) that mutating would be sufficient /if/ the compiler would view
  augmented assignment as mutations operators

 feel free to replace that += with an .add(1) method call; the point
 wasn't the behaviour of augmented assigment, the point was that that the
 most common use pattern involves *mutation* of the target object.

 the syntax isn't that important, really.

Mutation is different from rebinding.  A tuple is immutable, but you
can rebind the variable that refers to the tuple.  I think we will
confuse users if we use the term mutation to refer to name binding.
Name binding is already a subtle issue, so I think the risk is
significant.

Jeremy
___
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] Explicit Lexical Scoping (pre-PEP?)

[Jeremy Hylton]

On 7/10/06, Ka-Ping Yee [EMAIL PROTECTED] wrote:
 On Mon, 10 Jul 2006 [EMAIL PROTECTED] wrote:
  I think Talin's got a point though.  It seems hard to find one short English
  word that captures the essence of the desired behavior.  None of the words
  in his list seem strongly suggestive of the meaning to me.  I suspect that
  means one's ultimately as good (or as bad) as the rest.

 What's wrong with nonlocal?  I don't think i've seen an argument
 against that one so far (from Talin or others).

It's a made-up word.  You won't find it in the dictionary and the
google define: query sends me to a wikipedia page about quantum
mechanics.  It also expresses itself in the negative form not local
as opposed to the positive form like global this is a global.
Finally, I think it sounds yucky.

To express this email in the positive form:
1. Reserved words should be real words.
2. The meaning of the word should be clear.
3. Put statements in positive form.  (Strunk  White)
4. The word should sound good.

global meets all of these requirements.  free was the word I
remember preferring from earlier discussions, but I think it fails #2.
 (Too much confusion about freeing memory, for example.)

Jeremy



 -- ?!ng
 ___
 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/jeremy%40alum.mit.edu

___
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] Explicit Lexical Scoping (pre-PEP?)

[Jeremy Hylton]

On 7/10/06, Ka-Ping Yee [EMAIL PROTECTED] wrote:
 On 7/10/06, Ka-Ping Yee [EMAIL PROTECTED] wrote:
  What's wrong with nonlocal?  I don't think i've seen an argument
  against that one so far (from Talin or others).

 On Mon, 10 Jul 2006, Jeremy Hylton wrote:
  It's a made-up word.  You won't find it in the dictionary and the
  google define: query sends me to a wikipedia page about quantum
  mechanics.

 Two million Google hits for nonlocal seems like plenty.
 The explanation of nonlocal is pretty straightforward --

 If the definition of f() contains an assignment to x, then
 x is a local variable in f, unless x is declared nonlocal.

  To express this email in the positive form:
  1. Reserved words should be real words.
  2. The meaning of the word should be clear.
  3. Put statements in positive form.  (Strunk  White)
  4. The word should sound good.
 
  global meets all of these requirements.

 But it's the wrong word.  Purple also meets all of these requirements.

No.  Don't be silly.

The current use of global meets the requirements.  The meaning there
is clear, because global means global namespace.  If purple were a
keyword, I wouldn't know what it means.  I was not proposing the use
of global for some other meaning (and thought I made that clear in the
remainder of the message).

Jeremy


 I'd rather accurately express the concept in the negative (the
 true meaning really is in the negative: don't make a new binding),
 than choose a simple-sounding word that is essentially a lie.

 x = 1

 def f(x):
 print x

 def g():
 global x
 x = 3
 print x

 The x used in g is not global at all -- it belongs to f.


 -- ?!ng

___
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] Python sprint at Google Aug. 21-24

[Jeremy Hylton]

We'd like to invite you to attend a Python development sprint at
Google the week of Aug. 21.  We will be hosting sprints on two
coasts--at Google HQ in Mountain View CA and at our New York City
office.  You can find more information here:

http://wiki.python.org/moin/GoogleSprint

The sprint will occur just after the Python 2.5 release, assuming the
schedule doesn't slip.  It will be a great opportunity to get started
on Python 2.6 and Python 3000 work.  We hope to get some time for
face-to-face discussion about Python 3000 issues.  (We're expecting to
have a video conference hookup between the two sprints so that
everyone can participate equally.)

Google will provide the basic infrastructure for sprinting--desk
space, network connectivity, and food.  You need to bring your laptop
and your coding skills.  The wiki page has more details about
locations, hotels, c.  We'll keep it up to date with all the
logistical information about the sprint.

The sprints are sponsored by the Open Source Program Office at Google.
 We'd like to thank Chris DiBona and Leslie Hawthorn for their
enthusiastic support!

Please send any questions about logistics to Neal and me.  I assume we
can discuss the actual technical work on python-dev as usual.

Jeremy  Neal
(co-organizers)
___
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] 2.5 issues need resolving in a few days

[Jeremy Hylton]

I will be looking at the open AST issues today.

Jeremy

On 6/9/06, Neal Norwitz [EMAIL PROTECTED] wrote:
 The most important outstanding issue is the xmlplus/xmlcore issue.
 It's not going to get fixed unless someone works on it.  There's only
 a few days left before beta 1.  Can someone please address this?  If
 that means reverting changes to maintain compatibility, so be it.

 There is still the missing documentation for ctypes and element tree.
 I know there's been progress on ctypes.  What are we going to do about
 ElementTree?  Are we going to have another undocumented module in the
 core or should we pull ET out (that would also fix the xml issue)?

 Finally, there are the AST regressions.

 If there are patches that address any of these issues, respond with a link 
 here.

 I'm guessing that all the possible features are not going to make it into 2.5.

 n

___
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] Is implicit underscore assignment buggy?

[Jeremy Hylton]

On 6/7/06, Raymond Hettinger [EMAIL PROTECTED] wrote:
  for users, it's actually quite simple to figure out what's in the _
  variable: it's the most recently *printed* result.  if you cannot see
  it, it's not in there.

 Of course, there's a pattern to it.  The question is whether it is the *right*
 behavior.  Would the underscore assignment be more useful and intuitive
 if it always contained the immediately preceding result, even if it was None?
 In some cases (such as the regexp example), None is a valid and useful
 possible result of a computation and you may want to access that result with 
 _.

If you're using _ in an interactive environment, it's usually because
you don't want to re-type the value of the expression.  If the value
is None, it isn't hard to type.

 BTW, there is a trivial exception to the most recently printed result rule.

  13
 13
  _ = None
  _   # _ is no longer the most recently printed result

If you want to assign to _, the results are your own fault.

Jeremy
___
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 Logging questions (PEP 337 SoC)

[Jeremy Hylton]

On 6/6/06, Fredrik Lundh [EMAIL PROTECTED] wrote:
 Jim Jewett wrote:

  For pkgutil in particular, the change is that instead of writing to
  stderr (which can scroll off and get lost), it will write to the
  errorlog.  In a truly default setup, that still ends up writing to
  stderr.

 umm.  if pkgutil fails to open a pkg file, isn't it rather likely that
 the program will terminate with an ImportError a few milliseconds later?

Maybe a mean time of a few milliseconds later.  It really depends on
the operating system's scheduler.  If the failure occurs just at the
end of a scheduler quantum, the process may not run again for some
time.  This would happen regardless of whether the operating system
was modern.

Jeremy
___
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] PySequence_Fast_GET_ITEM in string join

[Jeremy Hylton]

On 5/23/06, Andrew Dalke [EMAIL PROTECTED] wrote:
 Me [Andrew Dalke] said:
  The relevant code in stringobject uses PySequence_Fast_GET_ITEM(seq,
  i),
  which likely doesn't know about my derived __getitem__.

 Oops, I didn't know what the code was doing well enough.  The
 relevant problem is

  seq = PySequence_Fast(orig, );

 That calls __iter__ on my derived list object, which knows nothing
 about my overridden __getitem__

Put another way, the problem is related to your initial claim:
 I can derive from list and override __getitem__

You can do that, but you should not.  It's almost a bug that you can.

Jeremy



 So things are working as designed.

 Well, back to blundering about.  Too much brennivin. ;)

 Andrew
 [EMAIL PROTECTED]

 ___
 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/jeremy%40alum.mit.edu

___
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] 2.5a1 Performance

[Jeremy Hylton]

On 4/18/06, M.-A. Lemburg [EMAIL PROTECTED] wrote:
 Anthony Baxter wrote:
  On Thursday 06 April 2006 04:10, Benji York wrote:
  On a related note: it might be nice to put a pystone run in the
  buildbot so it'd be easier to compare pystones across different
  releases, different architectures, and between particular changes
  to the code. (That's assuming that the machines are otherwise idle,
  though.) --
  -1.
 
  A bad benchmark (which pystone is) is much worse than no benchmark.

 I could contribute pybench to the Tools/ directory if that
 makes a difference:

I'd find that helpful.

Jeremy


 pybench -- The Python Benchmark Suite

 Extendable suite of of low-level benchmarks for measuring
   the performance of the Python implementation
   (interpreter, compiler or VM).

 

 WHAT IS IT ?:

 pybench is a collection of tests that provides a standardized way
 to measure the performance of Python implementations. It takes a
 very close look at different aspects of Python programs and let's
 you decide which factors are more important to you than others,
 rather than wrapping everything up in one number, like the other
 performance tests do (e.g. pystone which is included in the Python
 Standard Library).

 pybench has been used in the past by several Python developers to
 track down performance bottlenecks or to demonstrate the impact
 of optimizations and new features in Python.

 There's currently no documentation and no distutils support in
 pybench; that'll go into one of the next releases. For now,
 please read the source code. The command line interface for pybench
 is the file pybench.py. Run this script with option '--help'
 to get a listing of the possible options. Without options,
 pybench will simply execute the benchmark and then print out
 a report to stdout. Here's some sample output:
 
 Tests:  per runper oper.   overhead
 --
   BuiltinFunctionCalls: 131.50 ms1.03 us0.50 ms
BuiltinMethodLookup: 195.85 ms0.37 us1.00 ms
  CompareFloats: 126.00 ms0.28 us1.00 ms
  CompareFloatsIntegers: 201.05 ms0.45 us0.50 ms
CompareIntegers: 192.05 ms0.21 us2.00 ms
 CompareInternedStrings: 117.65 ms0.24 us3.50 ms
 ...
  TryExcept: 289.75 ms0.19 us3.00 ms
 TryRaiseExcept: 179.05 ms   11.94 us1.00 ms
   TupleSlicing: 159.75 ms1.52 us0.50 ms
UnicodeMappings: 171.85 ms9.55 us1.00 ms
  UnicodePredicates: 152.05 ms0.68 us4.00 ms
  UnicodeProperties: 203.00 ms1.01 us4.00 ms
 UnicodeSlicing: 190.10 ms1.09 us2.00 ms
 --
 Average round time:   10965.00 ms
 

 This is the current version:

 http://www.lemburg.com/files/python/pybench-1.2.zip

 --
 Marc-Andre Lemburg
 eGenix.com

 Professional Python Services directly from the Source  (#1, Apr 18 2006)
  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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! 
 ___
 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/jeremy%40alum.mit.edu

___
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] building with C++

[Jeremy Hylton]

On 4/12/06, Anthony Baxter [EMAIL PROTECTED] wrote:
 The code is _nearly_ building fine. there's an issue in _sre.c with
 some code that either returns a Py_UNICODE* or an SRE_CHAR* (unsigned
 char*) in a void*. The code probably needs a refactoring to deal with
 that. There's also
 Python/compile.c: In function 'int compiler_compare(compiler*,
 _expr*)':
 Python/compile.c:3065: error: invalid cast from type 'void*' to type
 'cmpop_ty'
 Python/compile.c:3075: error: invalid cast from type 'void*' to type
 'cmpop_ty'
 which I haven't looked at yet. Anyone else is welcome to fix these.

The code in compile.c is pretty dodgy.  I'd like to think of a better
way to represent an array of cmpop_ty objects than casting ints to
void* and then back.

Jeremy

 To get past those two, I've been building just those two files with
 gcc, with make CC=gcc Python/compile.o Modules/_sre.o



 ___
 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/jeremy%40alum.mit.edu

___
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] building with C++

[Jeremy Hylton]

Looks good to me.  Why don't you check it in.

Jeremy

On 4/12/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:

 Jeremy The code in compile.c is pretty dodgy.  I'd like to think of a
 Jeremy better way to represent an array of cmpop_ty objects than
 Jeremy casting ints to void* and then back.

 http://python.org/sf/1469594

 might be a step in the right direction.

 I assigned it to Anthony.  Feel free to assign it back to me.

 Skip

___
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] pdb segfaults in 2.5 trunk?

[Jeremy Hylton]

On 4/10/06, Phillip J. Eby [EMAIL PROTECTED] wrote:
 Is anybody else getting this?

Neal had originally reported that test_trace failed with a segfault,
and it's essentially exercising the same code.  I don't see a failure
there or here at the moment.  If there is a bug, though, it's likely
to be in the line number table that the new compiler generates.



 Python 2.5a1 (trunk:45237, Apr 10 2006, 15:25:33)
 [GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2
 Type help, copyright, credits or license for more information.
   import pdb
   def x():
 ... if 'a' in 'b':
 ... pass
 ...
   pdb.run(x())
   string(1)module()
 (Pdb) s
 --Call--
   stdin(1)x()
 (Pdb) s
   stdin(2)x()
 (Pdb) s
 Segmentation fault

 It usually happens within a few 's' operations in pdb.


 def x():
...   if 'a' in 'b':
... pass
...
[34945 refs]
 pdb.run('x()')
 string(1)module()-None
(Pdb) s
--Call--
 stdin(1)x()
(Pdb) s
--Return--
 stdin(1)x()-None
(Pdb) s
--Return--
 string(1)module()-None
(Pdb) s
[35023 refs]

[35023 refs]
[11168 refs]

Will try with a non-debug build soon.

Jeremy
___
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] pdb segfaults in 2.5 trunk?

[Jeremy Hylton]

4On 4/10/06, Jeremy Hylton [EMAIL PROTECTED] wrote:
 On 4/10/06, Phillip J. Eby [EMAIL PROTECTED] wrote:
  Is anybody else getting this?

 Neal had originally reported that test_trace failed with a segfault,
 and it's essentially exercising the same code.  I don't see a failure
 there or here at the moment.  If there is a bug, though, it's likely
 to be in the line number table that the new compiler generates.


 
  Python 2.5a1 (trunk:45237, Apr 10 2006, 15:25:33)
  [GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2
  Type help, copyright, credits or license for more information.
import pdb
def x():
  ... if 'a' in 'b':
  ... pass
  ...
pdb.run(x())
string(1)module()
  (Pdb) s
  --Call--
stdin(1)x()
  (Pdb) s
stdin(2)x()
  (Pdb) s
  Segmentation fault
 
  It usually happens within a few 's' operations in pdb.


  def x():
 ...   if 'a' in 'b':
 ... pass
 ...
 [34945 refs]
  pdb.run('x()')
  string(1)module()-None
 (Pdb) s
 --Call--
  stdin(1)x()
 (Pdb) s
 --Return--
  stdin(1)x()-None
 (Pdb) s
 --Return--
  string(1)module()-None
 (Pdb) s
 [35023 refs]
 
 [35023 refs]
 [11168 refs]

 Will try with a non-debug build soon.

I don't see it in a non-debug build either.
Python 2.5a1 (trunk:43632M, Apr 10 2006, 15:41:31)
[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2
Type help, copyright, credits or license for more information.

Jeremy
___
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] 2.5a1 Performance

[Jeremy Hylton]

On 4/5/06, Benji York [EMAIL PROTECTED] wrote:
 Realizing that early releases don't normally perform as well as final
 releases, I ran pystone for 2.5a1 and compared with 2.4.2 (what I had
 handy).  2.5a1 got slightly more than 30k, while 2.4.2 gets slightly
 more than 35k (1.4 GHz, Pentium M, 1 Meg L2 cache).

We should verify that all the compiler optimizations that existed in
Python 2.4 still exist in Python 2.5.  We didn't expend much effort in
that area during the compiler development.  Not sure if there are any
that would affect pystone or not.

Jeremy


 I also ran a large test suite for a project with both 2.5a1 and 2.4.2
 and got nearly identical times.

 I haven't seen general performance mentioned here lately, so I thought
 I'd share those numbers.

 On a related note: it might be nice to put a pystone run in the buildbot
 so it'd be easier to compare pystones across different releases,
 different architectures, and between particular changes to the code.
 (That's assuming that the machines are otherwise idle, though.)
 --
 Benji York
 ___
 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/jeremy%40alum.mit.edu

___
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] tally (and other accumulators)

[Jeremy Hylton]

On 4/4/06, Alex Martelli [EMAIL PROTECTED] wrote:
 import collections
 def tally(seq):
  d = collections.defaultdict(int)
  for item in seq:
  d[item] += 1
  return dict(d)

 Nevertheless, simplicity and generality make it advisable to supply
 it as part of the standard library (location TBD).

 A good alternative would be a classmethod tally within
 collections.defaultdict, building and returning a defaultdict as
 above (with a .factory left to int, for further possible use as a
 'bag'/multiset data structure); this would solve the problem of where
 to locate tally if it were to be a function.  defaultdict.tally would
 be logically quite similar to dict.fromkeys, except that keys
 happening repeatedly get counted (and so each associated to a value
 of 1 and upwards) rather than collapsed.

Putting it somewhere in collections seems like a great idea. 
defaultdict is a bit odd, because the functionality doesn't have
anything to do with defaults, just dicts.  maybe a classmethod on
regular dicts would make more sense?

I write this function regularly, so I'd be happy to have it available directly.

Jeremy
___
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] line numbers, pass statements, implicit returns

[Jeremy Hylton]

On 4/2/06, Guido van Rossum [EMAIL PROTECTED] wrote:
 On 4/1/06, Jeremy Hylton [EMAIL PROTECTED] wrote:
  There are several test cases in test_trace that are commented out.  We
  did this when we merged the ast-branch and promised to come back to
  them.  I'm coming back to them now, but the test aren't documented
  well and the feature they test isn't specified well.
 
  The failing tests I've looked at so far involving pass statements and
  implicit return None statements generated by the compiler.  The
  tests seem to verify that
 
  1) if you have a function that ends with an if/else where the body
  of the else is pass,
  there is no line number associated with the return
  2) if you have a function that ends with a try/except where the
  body of the except is pass,
  there is a line number associated with the return.
 
  Here's a failing example
 
  def ireturn_example():
  a = 5
  b = 5
  if a == b:
  b = a+1
  else:
  pass
 
  The code is traced and test_trace verifies that the return is
  associated with line 4!
 
  In these cases, the ast compiler will always associate a line number
  with the return.  (Technically with the LOAD_CONST preceding the
  RETURN_VALUE.)  This happens pretty much be accident.  It always
  associates a line number with the first opcode generated after a new
  statement is visited.  Since a Pass statement node has no opcode, the
  return generates the first opcode.
 
  Now I could add some special cases to the compiler to preserve the old
  behavior, the question is: Why bother?  It's such an unlikely case (an
  else that has no effect).  Does anyone depend on the current behavior
  for the ireturn_example()?  It seems sensible to me to always generate
  a line number for the pass + return case, just so you see the control
  flow as you step through the debugger.

 Makes sense to me. I can't imagine what this was testing except
 perhaps a corner case in the algorithm for generating the (insanely
 complicated) linenumber mapping table.

  The other case that has changed is that the new compiler does not
  generate code for while 0:  I don't remember why 0.5 wink.  There
  are several test cases that verify line numbers for code using this
  kind of bogus construct.  There are no lines anymore, so I would
  change the tests so that they don't expect the lines in question.  But
  I have no idea what they are trying to test.  Does anyone know?

 Not me. This is definitely not part of the language spec! :-)

It needs to be part of some spec, I think.  It's probably part of the
implementation rather than the language, but we need some description
of what the trace hooks are supposed to do.  The unittests are some
kind of spec, but not a great one (because they don't seem exhaustive
and don't explain why they work the way they do).  Should we write an
informational PEP, then, that explains the conditions under which you
get a line event in trace mode?  And how much do we care about
compatibility from release to release?

Here's another case that came up while pursuing these tests.  It looks
like the old compiler generated lnotab entries with a 0 change in line
number, merely so that the trace code would generate an event on that
line.  The problem case is a for loop, where there is a line number
set for the SETUP_LOOP instruction.  You'd like a line event for the
last time through the for loop, when the iterator is consumed, and to
get that it appears that the lnotab has an entry with a 0 increment in
line number and a non-zero increment in bytecode offset.  There's no
comment in the lnotab code that mentions that as a possibility, so it
came as a surprise to me :-).  The question, then, is how many cases
are there like this.  It may only be possible to answer this by
walking through the old compiler code and noting all the uncommented
special cases.

Looks like a project for alpha 2.

Jeremy
___
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] line numbers, pass statements, implicit returns

[Jeremy Hylton]

There are several test cases in test_trace that are commented out.  We
did this when we merged the ast-branch and promised to come back to
them.  I'm coming back to them now, but the test aren't documented
well and the feature they test isn't specified well.

The failing tests I've looked at so far involving pass statements and
implicit return None statements generated by the compiler.  The
tests seem to verify that

1) if you have a function that ends with an if/else where the body
of the else is pass,
there is no line number associated with the return
2) if you have a function that ends with a try/except where the
body of the except is pass,
there is a line number associated with the return.

Here's a failing example

def ireturn_example():
a = 5
b = 5
if a == b:
b = a+1
else:
pass

The code is traced and test_trace verifies that the return is
associated with line 4!

In these cases, the ast compiler will always associate a line number
with the return.  (Technically with the LOAD_CONST preceding the
RETURN_VALUE.)  This happens pretty much be accident.  It always
associates a line number with the first opcode generated after a new
statement is visited.  Since a Pass statement node has no opcode, the
return generates the first opcode.

Now I could add some special cases to the compiler to preserve the old
behavior, the question is: Why bother?  It's such an unlikely case (an
else that has no effect).  Does anyone depend on the current behavior
for the ireturn_example()?  It seems sensible to me to always generate
a line number for the pass + return case, just so you see the control
flow as you step through the debugger.

The other case that has changed is that the new compiler does not
generate code for while 0:  I don't remember why 0.5 wink.  There
are several test cases that verify line numbers for code using this
kind of bogus construct.  There are no lines anymore, so I would
change the tests so that they don't expect the lines in question.  But
I have no idea what they are trying to test.  Does anyone know?

Jeremy
___
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] Python Regression Test Failures all (1)

[Jeremy Hylton]

On 3/1/06, Neal Norwitz [EMAIL PROTECTED] wrote:
 test_bsddb3
 Exception in thread reader 4:
 Traceback (most recent call last):
   File /home/neal/python/trunk/Lib/threading.py, line 473, in __bootstrap
 self.run()
   File /home/neal/python/trunk/Lib/threading.py, line 453, in run
 self.__target(*self.__args, **self.__kwargs)
   File /home/neal/python/trunk/Lib/bsddb/test/test_thread.py, line 275, in 
 readerThread
 rec = dbutils.DeadlockWrap(c.next, max_retries=10)
   File /home/neal/python/trunk/Lib/bsddb/dbutils.py, line 62, in 
 DeadlockWrap
 return function(*_args, **_kwargs)
 DBLockDeadlockError: (-30996, 'DB_LOCK_DEADLOCK: Locker killed to resolve a 
 deadlock')

 Exception in thread writer 0:
 Traceback (most recent call last):
   File /home/neal/python/trunk/Lib/threading.py, line 473, in __bootstrap
 self.run()
   File /home/neal/python/trunk/Lib/threading.py, line 453, in run
 self.__target(*self.__args, **self.__kwargs)
   File /home/neal/python/trunk/Lib/bsddb/test/test_thread.py, line 254, in 
 writerThread
 self.assertEqual(data, self.makeData(key))
   File /home/neal/python/trunk/Lib/unittest.py, line 334, in failUnlessEqual
 (msg or '%r != %r' % (first, second))
 AssertionError: None != '0003-0003-0003-0003-0003'

 Exception in thread writer 1:
 Traceback (most recent call last):
   File /home/neal/python/trunk/Lib/threading.py, line 473, in __bootstrap
 self.run()
   File /home/neal/python/trunk/Lib/threading.py, line 453, in run
 self.__target(*self.__args, **self.__kwargs)
   File /home/neal/python/trunk/Lib/bsddb/test/test_thread.py, line 254, in 
 writerThread
 self.assertEqual(data, self.makeData(key))
   File /home/neal/python/trunk/Lib/unittest.py, line 334, in failUnlessEqual
 (msg or '%r != %r' % (first, second))
 AssertionError: None != '1000-1000-1000-1000-1000'

I haven't run regrtest.py -u all in a while.  Are these sorts of
errors just tolerated?

Jeremy
___
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] Documenting the ssize_t Python C API changes

[Jeremy Hylton]

On 3/21/06, M.-A. Lemburg [EMAIL PROTECTED] wrote:
 Don't you think developers are capable enough to judge for
 themselves ?

 They might also want to change their extensions to make use
 of the new possibilities, so a list of APIs taking Py_ssize_t
 parameters on input would be handy to check where there's
 potential for such a change in their code.

 Perhaps we should have three lists:

 1. Py_ssize_t output parameters (these need changes)
 2. Py_ssize_t return values (these need overflow checks)
 3. Py_ssize_t input parameters (these can be used to enhance
the extension)

It sounds more like the PEP should list these three categories and
tell developers that they need to inspect their code for instances of
them and fix them in the appropriate way.  Perhaps with an example of
each.

Jeremy
___
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] Bug Day?

[Jeremy Hylton]

On 3/15/06, Georg Brandl [EMAIL PROTECTED] wrote:
 Neil Schemenauer wrote:
  I think it would be a good idea to follow the Plone project and try
  to encourage new developers by offering assistance to get them up
  and running.  AFAIK, we've done that for the other bug days but it
  might help to publish the fact that no prior Python development
  experience is necessary.

 That's right, though I guess it'll be hard to find new core developers.
 Unfortunately, for most people developing _with_ Python is much more fun than
 developing Python.

 Settling on Friday, how about the 31st of March?

Sounds good to me.

Jeremy

 If that's okay for the VIPs, I will send out announcements on python-list, the
 non-english newsgroups and lists and ask Tim to place it on the website.

 Georg

 ___
 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/jeremy%40alum.mit.edu

___
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] r43033 - in python/trunk/Lib: distutils/sysconfig.py encodings/__init__.py

[Jeremy Hylton]

On 3/15/06, Guido van Rossum [EMAIL PROTECTED] wrote:
 Well, absolute imports without the future statement will not use the
 5th argument, so they won't break, right? That's what MAL also says.
 Someone please fix this.

I'd much rather see us change imports to use absolute imports than to
use relative imports in count-the-dots fashion.  Could we add that to
PEP 8?

Jeremy


 On 3/15/06, Thomas Wouters [EMAIL PROTECTED] wrote:
 
 
  On 3/15/06, guido.van.rossum [EMAIL PROTECTED] wrote:
  
   Use relative imports in a few places where I noticed the need.
   (Ideally, all packages in Python 2.5 will use the relative import
   syntax for all their relative import needs.)
 
 
  You should be aware that using relative imports (or absolute imports) in the
  standard library may cause custom __import__'s that don't take the optional
  fifth argument to break, whereas using 'old-style' imports does not. I don't
  know how common custom __import__ hooks are, and adding the optional fifth
  argument is backwardly compatible, but I would personally not add absolute
  or relative imports to the oft-used parts of the stdlib until after 2.5.
 
  On the other hand, code using sys.path_hooks (like zipimport) don't need any
  tweaking, as the absolute/relative choice is made before they are queried,
  so I don't know howmuch impact this has, all in all.
 
  --
  Thomas Wouters [EMAIL PROTECTED]
 
  Hi! I'm a .signature virus! copy me into your .signature file to help me
  spread!
  ___
  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/guido%40python.org
 
 
 


 --
 --Guido van Rossum (home page: http://www.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/jeremy%40alum.mit.edu

___
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] Bug Day?

[Jeremy Hylton]

On 3/8/06, Georg Brandl [EMAIL PROTECTED] wrote:
 I know, PyCon's just been, but not many bugs were closed and
 there really ought to be some issues resolved before 2.4.3 happens.
 The number of open bugs is again crawling to 900.

 I myself are looking at many bugs and patches over time, but with
 most of them I can't decide alone what to do. Writing here every
 time doesn't seem like the most sensible thing too.

 So, is there interest? Can I do anything to make it easier?

Would anyone be interested in a bug day on a weekday?  I don't have
time on weekends, but could probably find some time on a Wed or Fri
for bug fixing.  I'll probably do it regardless, but I'd have more fun
if a few others were online.

Jeremy
___
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] conditional expressions - add parens?

[Jeremy Hylton]

On 3/6/06, Alex Martelli [EMAIL PROTECTED] wrote:

 On Mar 6, 2006, at 9:17 AM, Jim Jewett wrote:
 ...
  I think that adding parentheses would help, by at least signalling
  that the logic is longer than just the next (single) expression.
 
  level = (0 if absolute_import in self.futures else -1)

 +1 (just because I can't give it +3.1415926...!!!).  *Mandatory*
 parentheses make this form MUCH more readable.

Recent language features seem to be suffereing from excessive
parenthesisitis.  I worry that people will stop remembering which
expressions requirement parens in which context.  Perhaps the solution
is to require parens around all expressions, a simple consistent rule.
 If so, then adding parens around all statements is a fairly natural
extension, which solves a number of problems like how to make a richer
lambda.

Jeremy
___
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] Coverity Open Source Defect Scan of Python

[Jeremy Hylton]

On 3/6/06, Thomas Wouters [EMAIL PROTECTED] wrote:



 On 3/6/06, Barry Warsaw [EMAIL PROTECTED] wrote:
   Didn't we set up a security swat team some time ago?  If not, we
   should.  Regardless, since I have more free time these days, I'd like
   to be on it.
 
  Yep, it's called [EMAIL PROTECTED] (with a semi-secret backing mailing
  list, which I'd be happy for you to join
!).  I definitely think that
  group of folks at the least should review the results.


 Well, if we start volunteering here, I'll volunteer as well. (For either
 group.) Can't let Tim have all the fun!

I also sent mail to Ben volunteering.  I expect the scope of defects
recognized is larger than just security.  In particular, the compiler
has a large body of code that has never been released before.  It
would nice to catch a few of its bugs before a release :-).

Jeremy
___
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] iterator API in Py3.0

[Jeremy Hylton]

On 3/3/06, Raymond Hettinger [EMAIL PROTECTED] wrote:
 The double underscore convention is appropriate where the method is always
 invoked magically in normal code and not called directly.  The next() method 
 is
 differenct because it is a mixed case, sometimes called magically and 
 sometimes
 called directly.  In the latter case, the name is highly visible and therefore
 should not have double underscores.

 I suspect that those who feel differently are ones who usually avoid calling
 next() directly.  That's okay, but we shouldn't muck-up the naming for the 
 rest
 of us who often do have a need to use next().

 This is doubly important because we're now expanding the protocol to include
 send() and throw().  Adding underscores around them too will only make those
 methods look harder to use than they actually are.  Don't underestimate the
 psychological revulsion to calling code filled with piles of double 
 underscores.

I think it is a little odd that next is not spelled __next__, but I
appreciate the reasons given here in particular.  Every time I right
.next(), I'm happy that it doesn't have underscores.

Jeremy
___
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] iterator API in Py3.0

[Jeremy Hylton]

On 3/3/06, Phillip J. Eby [EMAIL PROTECTED] wrote:
 At 04:09 PM 3/3/2006 -0500, Jeremy Hylton wrote:
 I think it is a little odd that next is not spelled __next__, but I
 appreciate the reasons given here in particular.  Every time I right
 .next(), I'm happy that it doesn't have underscores.

 But then next(ob) should make you even happier, because then there's no
 '.', either.  :)

I've got no problem with dots.  No shift key necessary :-).

On the subject of predilections and builtins, I find myself typing
.size() a lot lately.  Too much C++, I guess, but it seems so natural
as I type it.

Jeremy
___
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] quick status report

[Jeremy Hylton]

I made a few more minor revisions to the AST on the plane this
afternoon.  I'll check them in tomorrow when I get a chance to do a
full test run.

* Remove asdl_seq_APPEND.  All uses replaced with set
* Fix set_context() comments and check return value every where.
* Reimplement real arena for pyarena.c

Jeremy
___
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 for Better Control of Nested Lexical Scopes

[Jeremy Hylton]

On 2/24/06, James Y Knight [EMAIL PROTECTED] wrote:
 On Feb 24, 2006, at 1:54 AM, Greg Ewing wrote:
  Thomas Wouters wrote:
  On Thu, Feb 23, 2006 at 05:25:30PM +1300, Greg Ewing wrote:
 
  As an aside, is there any chance that this could be
  changed in 3.0? I.e. have the for-loop create a new
  binding for the loop variable on each iteration.
 
  You can't do that without introducing a whole new scope
  for the body of the 'for' loop,
 
  There's no need for that. The new scope need only
  include the loop variable -- everything else could
  still refer to the function's main scope.

 No, that would be insane. You get the exact same problem, now even
 more confusing:

 l=[]
 for x in range(10):
y = x
l.append(lambda: (x, y))

 print l[0]()

 With your suggestion, that would print (0, 9).

 Unless python grows a distinction between creating a binding and
 assigning to one as most other languages have, this problem is here
 to stay.

The more practical complaint is that list comprehensions use the same
namespace as the block that contains them.  It's much easier to miss
an assignment to, say, i in a list comprehension than it is in a
separate statement in the body of a for loop.  Since list comps are
expressions, the only variable at issue is the index variable.  It
would be simple to fix by renaming, but I suspect we're stuck with the
current behavior for backwards compatibility reasons.

Jeremy
___
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 for Better Control of Nested Lexical Scopes

[Jeremy Hylton]

On 2/22/06, Greg Ewing [EMAIL PROTECTED] wrote:
 Mark Russell wrote:

  PEP 227 mentions using := as a rebinding operator, but rejects the
  idea as it would encourage the use of closures.

 Well, anything that facilitates rebinding in outer scopes
 is going to encourage the use of closures, so I can't
 see that as being a reason to reject a particular means
 of rebinding. You either think such rebinding is a good
 idea or not -- and that seems to be a matter of highly
 individual taste.

At the time PEP 227 was written, nested scopes were contentious.  (I
recall one developer who said he'd be embarassed to tell his
co-workers he worked on Python if it had this feature :-).  Rebinding
was more contentious, so the feature was left out.  I don't think any
particular syntax or spelling for rebinding was favored more or less.

 On this particular idea, I tend to think it's too obscure
 as well. Python generally avoids attaching randomly-chosen
 semantics to punctuation, and I'd like to see it stay
 that way.

I agree.

Jeremy
___
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 for Better Control of Nested Lexical Scopes

[Jeremy Hylton]

Almann,

The lack of support for rebinding names in enclosing scopes is
certainly a wart.  I think option one is a better fit for Python,
because it more closely matches the existing naming semantics.  Namely
that assignment in a block creates a new name unless a global
statement indicates otherwise.  The revised rules would be that
assignment creates a new name unless a global or XXX statement
indicates otherwise.

The names of naming statements are quite hard to get right, I fear.  I
don't particularly like use.  It's too generic.  (I don't
particularly like scope for option 2, either, for similar reasons. 
It doesn't indicate what kind of scope issue is being declared.)  The
most specifc thing I can think of is free to indicate that the
variable is free in the current scope.  It may be too specialized a
term to be familiar to most people.

I think free == global in the absence of other bindings.

Jeremy

On 2/20/06, Almann T. Goo [EMAIL PROTECTED] wrote:
 I am considering developing a PEP for enabling a mechanism to assign to free
 variables in a closure (nested function).  My rationale is that with the
 advent of PEP 227 , Python has proper nested lexical scopes, but can have
 undesirable behavior (especially with new developers) when a user makes
 wants to make an assignment to a free variable within a nested function.
 Furthermore, after seeing numerous kludges to solve the problem with a
 mutable object, like a list, as the free variable do not seem Pythonic.  I
 have also seen mention that the use of classes can mitigate this, but that
 seems, IMHO, heavy handed in cases when an elegant solution using a closure
 would suffice and be more appropriate--especially when Python already has
 nested lexical scopes.

  I propose two possible approaches to solve this issue:

  1.  Adding a keyword such as use that would follow similar semantics as
 global does today.  A nested scope could declare names with this keyword
 to enable assignment to such names to change the closest parent's binding.
 The semantic would be to keep the behavior we experience today but tell the
 compiler/interpreter that a name declared with the use keyword would
 explicitly use an enclosing scope.  I personally like this approach the most
 since it would seem to be in keeping with the current way the language works
 and would probably be the most backwards compatible.  The semantics for how
 this interacts with the global scope would also need to be defined (should
 use be equivalent to a global when no name exists all parent scopes, etc.)


 def incgen( inc = 1 ) :
a = 6
def incrementer() :
  use a
  #use a, inc -- list of names okay too
  a += inc
  return a
return incrementer

  Of course, this approach suffers from a downside that every nested scope
 that wanted to assign to a parent scope's name would need to have the use
 keyword for those names--but one could argue that this is in keeping with
 one of Python's philosophies that Explicit is better than implicit (PEP
 20).  This approach also has to deal with a user declaring a name with 
 use that is a named parameter--this would be a semantic error that could be
 handled like global  does today with a SyntaxError.

  2.  Adding a keyword such as scope that would behave similarly to
 JavaScript's  var keyword.  A name could be declared with such a keyword
 optionally and all nested scopes would use the declaring scope's binding
 when accessing or assigning to a particular name.  This approach has similar
 benefits to my first approach, but is clearly more top-down than the first
 approach.  Subsequent scope declarations would create a new binding at the
 declaring scope for the declaring and child scopes to use.  This could
 potentially be a gotcha for users expecting the binding semantics in place
 today.  Also the scope keyword would have to be allowed to be used on
 parameters to allow such parameter names to be used in a similar fashion in
 a child scope.


 def incgen( inc = 1 ) :
#scope inc -- allow scope declaration for bound parameters (not a big
 fan of this)
scope a = 6
def incrementer() :
  a += inc
  return a
return incrementer

  This approach would be similar to languages like JavaScript that allow for
 explicit scope binding with the use of var or more static languages that
 allow re-declaring names at lower scopes.  I am less in favor of this,
 because I don't think it feels very Pythonic.

  As a point of reference, some languages such as Ruby will only bind a new
 name to a scope on assignment when an enclosing scope does not have the name
 bound.  I do believe the Python name binding semantics have issues (for
 which the global keyword was born), but I feel that the fixing the
 Python semantic to a more Ruby-like one adds as many problems as it solves
 since the Ruby-like one is just as implicit in nature.  Not to mention the
 backwards compatibility impact is probably much larger.

 I would like the 

Re: [Python-Dev] PEP for Better Control of Nested Lexical Scopes

[Jeremy Hylton]

I had to lookup top-post :-).

On 2/21/06, Bengt Richter [EMAIL PROTECTED] wrote:
 On Tue, 21 Feb 2006 08:02:08 -0500, Jeremy Hylton [EMAIL PROTECTED] wrote:
 Jeremy
 Hey, only Guido is allowed to top-post. He said so ;-)

The Gmail UI makes it really easy to forget where the q

 But to the topic, it just occurred to me that any outer scopes could be given 
 names
 (including global namespace, but that would have the name global by default, 
 so
 global.x would essentially mean what globals()['x'] means now, except it would
 be a name error if x didn't pre-exist when accessed via 
 namespace_name.name_in_space notation.


 namespace g_alias  # g_alias.x becomes alternate spelling of global.x
 def outer():
 namespace mezzanine
 a = 123
 print a  # = 123
 print mezzanine.a  # = 123 (the name space name is visible and 
 functional locally)
 def inner():
 print mezzanine.a = 123
 mezznine.a =456
 inner()
 print a # = 456
 global.x = re-binds global x, name error if not preexisting.

 This would allow creating mezzanine like an attribute view of the slots in 
 that local namespace,
 as well as making namespace itself visible there, so the access to mezzanine 
 would look like a read access to
 an ordinary object named mezzanine that happened to have attribute slots 
 matching outer's local name space.

 Efficiency might make it desirable not to extend named namespaces with new 
 names, function locals being
 slotted in a fixed space tied into the frame (I think). But there are tricks 
 I guess.
 Anyway, I hadn't seen this idea before. Seems

 Regards,
 Bengt Richter

 
 On 2/20/06, Almann T. Goo [EMAIL PROTECTED] wrote:
  I am considering developing a PEP for enabling a mechanism to assign to 
  free
  variables in a closure (nested function).  My rationale is that with the
  advent of PEP 227 , Python has proper nested lexical scopes, but can have
  undesirable behavior (especially with new developers) when a user makes
  wants to make an assignment to a free variable within a nested function.
  Furthermore, after seeing numerous kludges to solve the problem with a
  mutable object, like a list, as the free variable do not seem Pythonic.  
  I
  have also seen mention that the use of classes can mitigate this, but that
  seems, IMHO, heavy handed in cases when an elegant solution using a closure
  would suffice and be more appropriate--especially when Python already has
  nested lexical scopes.
 
   I propose two possible approaches to solve this issue:
 
   1.  Adding a keyword such as use that would follow similar semantics as
  global does today.  A nested scope could declare names with this keyword
  to enable assignment to such names to change the closest parent's binding.
  The semantic would be to keep the behavior we experience today but tell the
  compiler/interpreter that a name declared with the use keyword would
  explicitly use an enclosing scope.  I personally like this approach the 
  most
  since it would seem to be in keeping with the current way the language 
  works
  and would probably be the most backwards compatible.  The semantics for how
  this interacts with the global scope would also need to be defined (should
  use be equivalent to a global when no name exists all parent scopes, 
  etc.)
 
 
  def incgen( inc = 1 ) :
 a = 6
 def incrementer() :
   use a
   #use a, inc -- list of names okay too
   a += inc
   return a
 return incrementer
 
   Of course, this approach suffers from a downside that every nested scope
  that wanted to assign to a parent scope's name would need to have the use
  keyword for those names--but one could argue that this is in keeping with
  one of Python's philosophies that Explicit is better than implicit (PEP
  20).  This approach also has to deal with a user declaring a name with 
  use that is a named parameter--this would be a semantic error that could 
  be
  handled like global  does today with a SyntaxError.
 
   2.  Adding a keyword such as scope that would behave similarly to
  JavaScript's  var keyword.  A name could be declared with such a keyword
  optionally and all nested scopes would use the declaring scope's binding
  when accessing or assigning to a particular name.  This approach has 
  similar
  benefits to my first approach, but is clearly more top-down than the first
  approach.  Subsequent scope declarations would create a new binding at 
  the
  declaring scope for the declaring and child scopes to use.  This could
  potentially be a gotcha for users expecting the binding semantics in place
  today.  Also the scope keyword would have to be allowed to be used on
  parameters to allow such parameter names to be used in a similar fashion in
  a child scope.
 
 
  def incgen( inc = 1 ) :
 #scope inc -- allow scope declaration for bound parameters (not a big
  fan of this)
 scope a = 6
 def incrementer

Re: [Python-Dev] PEP for Better Control of Nested Lexical Scopes

[Jeremy Hylton]

On 2/21/06, Jeremy Hylton [EMAIL PROTECTED] wrote:
 I had to lookup top-post :-).

 On 2/21/06, Bengt Richter [EMAIL PROTECTED] wrote:
  On Tue, 21 Feb 2006 08:02:08 -0500, Jeremy Hylton [EMAIL PROTECTED] 
  wrote:
  Jeremy
  Hey, only Guido is allowed to top-post. He said so ;-)

 The Gmail UI makes it really easy to forget where the q

Sorry about that.  Hit the send key by mistake.

The Gmail UI makes it really easy to forget where the quoted text is
in relation to your own text.

  But to the topic, it just occurred to me that any outer scopes could be 
  given names
  (including global namespace, but that would have the name global by 
  default, so
  global.x would essentially mean what globals()['x'] means now, except it 
  would
  be a name error if x didn't pre-exist when accessed via 
  namespace_name.name_in_space notation.

Isn't this suggestion that same as Greg Ewing's?

  namespace g_alias  # g_alias.x becomes alternate spelling of global.x
  def outer():
  namespace mezzanine
  a = 123
  print a  # = 123
  print mezzanine.a  # = 123 (the name space name is visible and 
  functional locally)
  def inner():
  print mezzanine.a = 123
  mezznine.a =456
  inner()
  print a # = 456
  global.x = re-binds global x, name error if not preexisting.
 
  This would allow creating mezzanine like an attribute view of the slots in 
  that local namespace,
  as well as making namespace itself visible there, so the access to 
  mezzanine would look like a read access to
  an ordinary object named mezzanine that happened to have attribute slots 
  matching outer's local name space.

I don't think using attribute access is particularly clear here.  It
introduces an entirely new concept, a first-class namespace, in order
to solve a small scoping problem.  It looks too much like attribute
access and not enough like accessing a variable.

Jeremy

  Efficiency might make it desirable not to extend named namespaces with new 
  names, function locals being
  slotted in a fixed space tied into the frame (I think). But there are 
  tricks I guess.
  Anyway, I hadn't seen this idea before. Seems
 
  Regards,
  Bengt Richter
 
  
  On 2/20/06, Almann T. Goo [EMAIL PROTECTED] wrote:
   I am considering developing a PEP for enabling a mechanism to assign to 
   free
   variables in a closure (nested function).  My rationale is that with the
   advent of PEP 227 , Python has proper nested lexical scopes, but can have
   undesirable behavior (especially with new developers) when a user makes
   wants to make an assignment to a free variable within a nested function.
   Furthermore, after seeing numerous kludges to solve the problem with a
   mutable object, like a list, as the free variable do not seem 
   Pythonic.  I
   have also seen mention that the use of classes can mitigate this, but 
   that
   seems, IMHO, heavy handed in cases when an elegant solution using a 
   closure
   would suffice and be more appropriate--especially when Python already has
   nested lexical scopes.
  
I propose two possible approaches to solve this issue:
  
1.  Adding a keyword such as use that would follow similar semantics 
   as
   global does today.  A nested scope could declare names with this 
   keyword
   to enable assignment to such names to change the closest parent's 
   binding.
   The semantic would be to keep the behavior we experience today but tell 
   the
   compiler/interpreter that a name declared with the use keyword would
   explicitly use an enclosing scope.  I personally like this approach the 
   most
   since it would seem to be in keeping with the current way the language 
   works
   and would probably be the most backwards compatible.  The semantics for 
   how
   this interacts with the global scope would also need to be defined 
   (should
   use be equivalent to a global when no name exists all parent scopes, 
   etc.)
  
  
   def incgen( inc = 1 ) :
  a = 6
  def incrementer() :
use a
#use a, inc -- list of names okay too
a += inc
return a
  return incrementer
  
Of course, this approach suffers from a downside that every nested scope
   that wanted to assign to a parent scope's name would need to have the 
   use
   keyword for those names--but one could argue that this is in keeping with
   one of Python's philosophies that Explicit is better than implicit (PEP
   20).  This approach also has to deal with a user declaring a name with 
   use that is a named parameter--this would be a semantic error that 
   could be
   handled like global  does today with a SyntaxError.
  
2.  Adding a keyword such as scope that would behave similarly to
   JavaScript's  var keyword.  A name could be declared with such a 
   keyword
   optionally and all nested scopes would use the declaring scope's binding
   when accessing or assigning to a particular name

Re: [Python-Dev] 2.5 release schedule

[Jeremy Hylton]

It is critical, but I hadn't seen the bug report.  Feel free to assign
AST bugs to me and assign them a  5 priority.

Jeremy

On 2/17/06, Armin Rigo [EMAIL PROTECTED] wrote:
 Hi,

 On Tue, Feb 14, 2006 at 09:24:57PM -0800, Neal Norwitz wrote:
  http://www.python.org/peps/pep-0356.html

 There is at least one SF bug, namely #1333982 Bugs of the new AST
 compiler, that in my humble opinion absolutely needs to be fixed before
 the release, even though I won't hide that I have no intention of fixing
 it myself.  Should I raise the issue here in python-dev, and see if we
 agree that it is critical?

 (Sorry if I should know about the procedure.  Does it then go in the
 PEP's Planned Features list?)


 A bientot,

 Armin
 ___
 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/jeremy%40alum.mit.edu

___
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] 2.5 release schedule

[Jeremy Hylton]

Actually, it might be easier to assign separate bugs.  A number of the
old bugs appear to have been fixed.  It's hard to track individual
items within a bug report.

Jeremy

On 2/17/06, Jeremy Hylton [EMAIL PROTECTED] wrote:
 It is critical, but I hadn't seen the bug report.  Feel free to assign
 AST bugs to me and assign them a  5 priority.

 Jeremy

 On 2/17/06, Armin Rigo [EMAIL PROTECTED] wrote:
  Hi,
 
  On Tue, Feb 14, 2006 at 09:24:57PM -0800, Neal Norwitz wrote:
   http://www.python.org/peps/pep-0356.html
 
  There is at least one SF bug, namely #1333982 Bugs of the new AST
  compiler, that in my humble opinion absolutely needs to be fixed before
  the release, even though I won't hide that I have no intention of fixing
  it myself.  Should I raise the issue here in python-dev, and see if we
  agree that it is critical?
 
  (Sorry if I should know about the procedure.  Does it then go in the
  PEP's Planned Features list?)
 
 
  A bientot,
 
  Armin
  ___
  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/jeremy%40alum.mit.edu
 

___
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] C AST to Python discussion

[Jeremy Hylton]

I am still -1 on the ast-objects branch.  It adds a lot of boilerplate
code and its makes complicated what is now simple.  I'll see if I can
get a rough cut of the marshal code ready today, so there will be a
complete implementation of my original plan.

I also think we should keep the transformation api simple.  If we
provide an extension module, along the lines of the parser module,
users can write transformations with that module.  They can also write
their own wrapper script that runs a script after applying
transformations.

I agree that the question of saved bytecode files still needs to be
resolved.  I'm not sure that extending the bytecode format to record
modifications is enough, since you also have a filename problem:  How
do you manage two versions of a module, one compiled with
transformation and one compiled without?

How about we arrange for some open space time at PyCon to discuss? 
Unfortunately, the compiler talk isn't until the last day and I can't
stay for sprints.  It would be better to have the talk, then the open
space, then the sprint.

Jeremy

On 2/15/06, Simon Burton [EMAIL PROTECTED] wrote:
 On Wed, 15 Feb 2006 00:34:35 -0800
 Brett Cannon [EMAIL PROTECTED] wrote:

  As per Neal's prodding email, here is a thread to discuss where we
  want to go with the C AST to Python stuff and what I think are the
  core issues at the moment.
 
  First issue is the ast-objects branch.  Work is being done on it, but
  it still leaks some references (Neal or Martin can correct me if I am
  wrong).

 I've been doing the heavy lifting on ast-objects the last few weeks.
 Today it finally passed the python test suite. The last thing to do is
 the addition of XDECREF's, so yes, it is leaking a lot of references.

 I won't make it to PyCon (it's a long way for me to come), but gee I've left
 all the fun stuff for you to do !
 :)

 Even if AST transforms are not allowed, I see it as the strongest form of
 code reflection, and long over-due in python.

 Simon.


 --
 Simon Burton, B.Sc.
 Licensed PO Box 8066
 ANU Canberra 2601
 Australia
 Ph. 61 02 6249 6940
 http://arrowtheory.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/jeremy%40alum.mit.edu

___
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] http://www.python.org/dev/doc/devel still available

[Jeremy Hylton]

As I said in an earlier message, there's no need to have a separate
domain to restrict queries to just the doc/current part of python.org.
 Just type
site:python.org/doc/current your query here

If there isn't any other rationale, maybe we can redirects
docs.python.org back to www.python.org?

Jeremy

On 2/15/06, Guido van Rossum [EMAIL PROTECTED] wrote:
 On 2/15/06, Tim Parkin [EMAIL PROTECTED] wrote:
  Guido van Rossum wrote:
 
   (Now that I work for Google I realize more than ever before the
   importance of keeping URLs stable; PageRank(tm) numbers don't get
   transferred as quickly as contents. I have this worry too in the
   context of the python.org redesign; 301 permanent redirect is *not*
   going to help PageRank of the new page.)

  Could you expand on why 301 redirects won't help with the transfer of
  page rank (if you're allowed)? We've done exactly this on many sites and
  the pagerank (or more relevantly the search rankings on specific terms)
  has transferred almost overnight. The bigger pagerank updates (both
  algorithm changes and overhauls in approach) seem to only happen every
  few months and these also seem to take notice of 301 redirects (they
  generally clear up any supplemental results).

 OK, perhaps I stand corrected. I don't actually know that much about PageRank!

 I still don't like docs.python.org, and adding more like it seems a
 mistake; but it's possible that this is because of a poor execution of
 the idea (there's no search docs button near the search button on
 the old python.org).

 --
 --Guido van Rossum (home page: http://www.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/jeremy%40alum.mit.edu

___
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] http://www.python.org/dev/doc/devel still available

[Jeremy Hylton]

I don't think this message is on-topic for python-dev.  There are lots
of great places to discuss the design of the python web site, but the
list for developers doesn't seem like a good place for it.  Do we need
a different list for people to gripe^H^H^H^H^H discuss the web site?

Jeremy

On 2/15/06, Fredrik Lundh [EMAIL PROTECTED] wrote:
 Tim Parkin wrote:

  As for cutting edge, it's using twisted, restructured text, nevow, clean
  urls, xhtml, semantic markup, css2, interfaces, adaption, eggs, the path
  module, moinmoin, yaml (to avoid xml),

 that's not cutting edge, that's buzzword bingo.

  something I don't think I would be qualified to judge,never mind receive).

 no, you're not qualified.  yet, someone gave you total control over the
 future of python.org, and there's no way to make you give it up, despite
 the fact that you're over a year late and the stuff you've delivered this
 far is massively underwhelming.  that's the problem.

 /F



 ___
 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/jeremy%40alum.mit.edu

___
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] Baffled by PyArg_ParseTupleAndKeywords modification

[Jeremy Hylton]

On 2/14/06, M.-A. Lemburg [EMAIL PROTECTED] wrote:
 Martin v. Löwis wrote:
  M.-A. Lemburg wrote:
  It's the consequences:  nobody complains about tacking const on to a
  former honest-to-God char * argument that was in fact not modified,
  because that's not only helpful for C++ programmers, it's _harmless_
  for all programmers.  For example, nobody could sanely object (and
  nobody did :-)) to adding const to the attribute-name argument in
  PyObject_SetAttrString().  Sticking to that creates no new problems
  for anyone, so that's as far as I ever went.
 
  Well, it broke my C extensions... I now have this in my code:
 
  /* The keyword array changed to const char* in Python 2.5 */
  #if PY_VERSION_HEX = 0x0205
  # define Py_KEYWORDS_STRING_TYPE const char
  #else
  # define Py_KEYWORDS_STRING_TYPE char
  #endif
  ...
  static Py_KEYWORDS_STRING_TYPE *kwslist[] = {yada, NULL};
  ...
 
  You did not read Tim's message carefully enough. He wasn't talking
  about PyArg_ParseTupleAndKeywords *at all*. He only talked about
  changing char* arguments to const char*, e.g. in
  PyObject_SetAttrString. Did that break your C extensions also?

 I did read Tim's post: sorry for phrasing the reply the way I did.

 I was referring to his statement nobody complains about tacking const
 on to a former honest-to-God char * argument that was in fact not
 modified.

 Also: it's not me complaining, it's the compilers !

Tim was talking about adding const to a char* not adding const to a
char** (note the two stars).  The subsequent discussion has been about
the different way those are handled in C and C++ and a general
agreement that the const char** has been a bother for people.

Jeremy
___
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] Baffled by PyArg_ParseTupleAndKeywords modification

[Jeremy Hylton]

On 2/14/06, Martin v. Löwis [EMAIL PROTECTED] wrote:
 Jeremy Hylton wrote:
  The compiler in question is gcc and the warning can be turned off with
  -Wno-write-strings.  I think we'd be better off leaving that option
  on, though.  This warning will help me find places where I'm passing a
  string literal to a function that does not take a const char*.  That's
  valuable, not insensate.

 Hmm. I'd say this depends on what your reaction to the warning is.
 If you sprinkle const_casts in the code, nothing is gained.

Except for the Python APIs, we would declare the function as taking a
const char* if took a const char*.  If the function legitimately takes
a char*, then you have to change the code to avoid a segfault.

 Perhaps there is some value in finding functions which ought to expect
 const char*. For that, occasional checks should be sufficient; I cannot
 see a point in having code permanently pass with that option. In
 particular not if you are interfacing with C libraries.

I don't understand what you mean:  I'm not sure what you mean by
occasional checks or permanently pass.  The compiler flags are
always the same.

Jeremy
___
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] Baffled by PyArg_ParseTupleAndKeywords modification

[Jeremy Hylton]

It sounds like the right answer for Python is to change the signature
of PyArg_ParseTupleAndKeywords() back.  We'll fix it when C fixes its
const rules wink.

Jeremy

On 2/13/06, Guido van Rossum [EMAIL PROTECTED] wrote:
 On 2/12/06, Greg Ewing [EMAIL PROTECTED] wrote:
[A large head-exploding set of rules]
 
  Blarg.
 
  Const - Just Say No.

 +1

 --
 --Guido van Rossum (home page: http://www.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/jeremy%40alum.mit.edu

___
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] Baffled by PyArg_ParseTupleAndKeywords modification

[Jeremy Hylton]

On 2/10/06, Martin v. Löwis [EMAIL PROTECTED] wrote:
 Jeremy Hylton wrote:
  Ok.  I reviewed the original problem and you're right, the problem was
  not that it failed outright but that it produced a warning about the
  deprecated conversion:
  warning: deprecated conversion from string constant to 'char*''
 
  I work at a place that takes the same attitude as python-dev about
  warnings:  They're treated as errors and you can't check in code that
  the compiler generates warnings for.

 In that specific case, I think the compiler's warning should be turned
 off; it is a bug in the compiler if that specific warning cannot be
 turned off separately.

The compiler in question is gcc and the warning can be turned off with
-Wno-write-strings.  I think we'd be better off leaving that option
on, though.  This warning will help me find places where I'm passing a
string literal to a function that does not take a const char*.  That's
valuable, not insensate.

Jeremy

 While it is true that the conversion is deprecated, the C++ standard
 defines this as

 Normative for the current edition of the Standard, but not guaranteed
 to be part of the Standard in future revisions.

 The current version is from 1998. I haven't been following closely,
 but I believe there are no plans to actually remove the feature
 in the next revision.

 FWIW, Annex D also defines these features as deprecated:
 - the use of static for objects in namespace scope (AFAICT
   including C file-level static variables and functions)
 - C library headers (i.e. stdio.h)

 Don't you get a warning when including Python.h, because that
 include limits.h?

  Nonetheless, the consensus on the c++ sig and python-dev at the time
  was to fix Python.  If we don't allow warnings in our compilations, we
  shouldn't require our users at accept warnings in theirs.

 We don't allow warnings for major compilers. This specific compiler
 appears flawed (or your configuration of 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] http://www.python.org/dev/doc/devel still available

[Jeremy Hylton]

On 2/13/06, Fred L. Drake, Jr. [EMAIL PROTECTED] wrote:
 On Monday 13 February 2006 15:40, Guido van Rossum wrote:
   Shouldn't docs.python.org be removed? It seems to add mroe confusion
   than anything, especially since most links on python.org continue to
   point to python.org/doc/.

 docs.python.org was created specifically to make searching the most recent
 stable version of the docs easier (using Google's site: modifier, no less).
 I don't know what the link count statistics say (other than what you
 mention), and don't know which gets hit more often, but I still think it's a
 reasonable approach.

Why not do a query like this?
http://www.google.com/search?q=site%3Apython.org/doc/current%20urllibhl=en

Jeremy
___
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] Baffled by PyArg_ParseTupleAndKeywords modification

[Jeremy Hylton]

On 2/10/06, Guido van Rossum [EMAIL PROTECTED] wrote:
 OMG. Are we now adding 'const' modifiers to random places? I thought
 const propagation hell was a place we were happily avoiding by not
 falling for that meme. What changed?

I added some const to several API functions that take char* but
typically called by passing string literals.  In C++, a string literal
is a const char* so you need to add a const_cast to every call site,
which is incredibly cumbersome.  After some discussion on python-dev,
I made changes to a small set of API functions and chased the
const-ness the rest of the way, as you would expect.  There was
nothing random about the places const was added.

I admit that I'm also puzzled by Jack's specific question.  I don't
understand why an array passed to PyArg_ParseTupleAndKeywords() would
need to be declared as const.  I observed the problem in my initial
changes but didn't think very hard about the cause of the problem. 
Perhaps someone with better C/C++ standards chops can explain.

Jeremy



 --Guido

 On 2/10/06, Jack Jansen [EMAIL PROTECTED] wrote:
  I keep running into problems with the const modifications to
  PyArg_ParseTupleAndKeywords() (rev. 41638 by Jeremy).
 
  I have lots of code of the form
  char *kw[] = {itself, 0};
 
  if (PyArg_ParseTupleAndKeywords(_args, _kwds, O, kw,
  CFTypeRefObj_Convert, itself)) ...
  which now no longer compiles, neither with C nor with C++ (gcc4, both
  MacOSX and Linux). Changing the kw declaration to const char *kw[]
  makes it compile again.
 
  I don't understand why it doesn't compile: even though the
  PyArg_ParseTupleAndKeywords signature promises that it won't change
  the kw argument I see no reason why I shouldn't be able to pass a
  non-const argument.
 
  And to make matters worse adding the const of course makes the code
  non-portable to previous versions of Python (where the C compiler
  rightly complains that I'm passing a const object through a non-const
  parameter).
 
  Can anyone enlighten me?
  --
  Jack Jansen, [EMAIL PROTECTED], http://www.cwi.nl/~jack
  If I can't dance I don't want to be part of your revolution -- Emma
  Goldman
 
 
  ___
  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/guido%40python.org
 


 --
 --Guido van Rossum (home page: http://www.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/jeremy%40alum.mit.edu

___
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] Baffled by PyArg_ParseTupleAndKeywords modification

[Jeremy Hylton]

It looks like a solution may be to define it as const char * const *
rather than const char **.  I'll see if that works.

Jeremy

On 2/10/06, Martin v. Löwis [EMAIL PROTECTED] wrote:
 Jeremy Hylton wrote:
  I admit that I'm also puzzled by Jack's specific question.  I don't
  understand why an array passed to PyArg_ParseTupleAndKeywords() would
  need to be declared as const.  I observed the problem in my initial
  changes but didn't think very hard about the cause of the problem.
  Perhaps someone with better C/C++ standards chops can explain.

 Please take a look at this code:

 void foo(const char** x, const char*s)
 {
 x[0] = s;
 }

 void bar()
 {
 char *kwds[] = {0};
 const char *s = Text;
 foo(kwds, s);
 kwds[0][0] = 't';
 }

 If it was correct, you would be able to modify the const char
 array in the string literal, without any compiler errors. The
 assignment

   x[0] = s;

 is kosher, because you are putting a const char* into a
 const char* array, and the assigment

  kwds[0][0] = 't';

 is ok, because you are modifying a char array. So the place
 where it has to fail is the passing of the pointer-pointer.

 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] Baffled by PyArg_ParseTupleAndKeywords modification

[Jeremy Hylton]

On 2/10/06, Martin v. Löwis [EMAIL PROTECTED] wrote:
 Jeremy Hylton wrote:
  I added some const to several API functions that take char* but
  typically called by passing string literals.  In C++, a string literal
  is a const char* so you need to add a const_cast to every call site,

 That's not true.

 A string literal of length N is of type const char[N+1]. However,
 a (deprecated) conversion of string literals to char* is provided
 in the language. So assigning a string literal to char* or passing
 it in a char* parameter is compliant with standard C++, no
 const_cast is required.

Ok.  I reviewed the original problem and you're right, the problem was
not that it failed outright but that it produced a warning about the
deprecated conversion:
warning: deprecated conversion from string constant to 'char*''

I work at a place that takes the same attitude as python-dev about
warnings:  They're treated as errors and you can't check in code that
the compiler generates warnings for.

Nonetheless, the consensus on the c++ sig and python-dev at the time
was to fix Python.  If we don't allow warnings in our compilations, we
shouldn't require our users at accept warnings in theirs.

Jeremy
___
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] Baffled by PyArg_ParseTupleAndKeywords modification

[Jeremy Hylton]

On 2/10/06, Jeremy Hylton [EMAIL PROTECTED] wrote:
 It looks like a solution may be to define it as const char * const *
 rather than const char **.  I'll see if that works.

No.  It doesn't work.  I'm not sure about this one either, but some
searching suggests that you can pass a char** to a function taking
const char* const* in C++ but not in C.  Sigh.  I don't see any way to
avoid a warning in Jack's case.

Jeremy


 Jeremy

 On 2/10/06, Martin v. Löwis [EMAIL PROTECTED] wrote:
  Jeremy Hylton wrote:
   I admit that I'm also puzzled by Jack's specific question.  I don't
   understand why an array passed to PyArg_ParseTupleAndKeywords() would
   need to be declared as const.  I observed the problem in my initial
   changes but didn't think very hard about the cause of the problem.
   Perhaps someone with better C/C++ standards chops can explain.
 
  Please take a look at this code:
 
  void foo(const char** x, const char*s)
  {
  x[0] = s;
  }
 
  void bar()
  {
  char *kwds[] = {0};
  const char *s = Text;
  foo(kwds, s);
  kwds[0][0] = 't';
  }
 
  If it was correct, you would be able to modify the const char
  array in the string literal, without any compiler errors. The
  assignment
 
x[0] = s;
 
  is kosher, because you are putting a const char* into a
  const char* array, and the assigment
 
   kwds[0][0] = 't';
 
  is ok, because you are modifying a char array. So the place
  where it has to fail is the passing of the pointer-pointer.
 
  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] Baffled by PyArg_ParseTupleAndKeywords modification

[Jeremy Hylton]

On 2/10/06, Tim Peters [EMAIL PROTECTED] wrote:
 [Jeremy]
 I added some const to several API functions that take char* but
 typically called by passing string literals.

 If he had _stuck_ to that, we wouldn't be having this discussion :-)
 (that is, nobody passes string literals to
 PyArg_ParseTupleAndKeywords's kws argument).

They are passing arrays of string literals.  In my mind, that was a
nearly equivalent use case.  I believe the C++ compiler complains
about passing an array of string literals to char**.

Jeremy
___
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] Baffled by PyArg_ParseTupleAndKeywords modification

[Jeremy Hylton]

On 2/10/06, Guido van Rossum [EMAIL PROTECTED] wrote:
 On 2/10/06, Tim Peters [EMAIL PROTECTED] wrote:
  [Jeremy]
  I added some const to several API functions that take char* but
  typically called by passing string literals.
 
  If he had _stuck_ to that, we wouldn't be having this discussion :-)
  (that is, nobody passes string literals to
  PyArg_ParseTupleAndKeywords's kws argument).

 Is it too late to revert this one?

The change is still beneficial to C++ programmers, so my initial
preference is to keep it.  There are still some benefits to the other
changes, so it's isn't a complete loss if we revert it.

 Is there another way to make C++ programmers happy (e.g. my having a
 macro that expands to const when compiled with C++ but vanishes when
 compiled with C?)

Sounds icky.  Are we pretty sure there is no way to do the right thing
in plain C?  That is, declare the argument as taking a set of const
strings and still allow non-const strings to be passed without
warning.

Jeremy
___
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] compiler.pyassem

[Jeremy Hylton]

On 2/10/06, Fabiano Sidler [EMAIL PROTECTED] wrote:
 Do I see things as they are and compiler.pyassem generates bytecode
 straight without involve any C code, i.e. code from the VM or the
 compiler? How is this achieved? I took a look at Python/compile.c as
 mentioned in compiler.pyassem and I'm trying to get into it, but about
 6500 lines of C code are too much for me in one file. Could someone
 here please give me some hints on how one can do what compiler.pyassem
 does?

I'm not sure what exactly you want to know.  The compiler package
implements most of a Python bytecode compiler in Python.  It re-uses
the parser written in C, but otherwise does the entire transformation
in Python.  The how is this achieved? question is hard to answer
without saying read the source.  There are about 6000 lines of
Python code in the compiler pacakge, but you can largely ignore ast.py
and transformer.py if you just want to study the compiler.

Perhaps you specific question is: How does the interpreter create new
bytecode or function objects from a program instead of compiling from
source or importing a module?  At some level, bytecode is simply a
string representation of a progam.  The new module takes the bytecode
plus a lot of meta-data including the names of variables and a list of
constants, and produces a new code object.  See the newCodeObject()
method.

I suspect further discussion on this topic might be better done on
python-list, unless you have some discussion that is relevant for
Python implementors.

Jeremy
___
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] _length_cue()

[Jeremy Hylton]

Hint seems like the standard terminology in the field.  I don't think
it makes sense to invent our own terminology without some compelling
reason.

Jeremy



On 2/9/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:

  [Andrew Koenig]
 
  Might I suggest that at least you consider using hint instead of 
 cue?
 ...

 Greg I agree that hint is a more precise name.

 Ditto.  In addition, we already have queues.  Do we really need to use a
 homonym that means something entirely different?  (Hint: consider the added
 difficulty for non-native English speakers).

 Skip
 ___
 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/jeremy%40alum.mit.edu

___
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 plan for 2.5 ?

[Jeremy Hylton]

It looks like we need a Python 2.5 Release Schedule PEP.

Jeremy

On 2/7/06, Neal Norwitz [EMAIL PROTECTED] wrote:
 On 2/7/06, Fredrik Lundh [EMAIL PROTECTED] wrote:
  
   what's the current release plan for Python 2.5, btw?  I cannot find a
   relevant PEP, and the what's new says late 2005:
  
  but I don't think that anyone followed up on this.  what's the current
  status ?

 Guido and I had a brief discussion about this.  IIRC, he was thinking
 alpha around March and release around summer.  I think this is
 aggressive with all the things still to do.  We really need to get the
 ssize_t branch integrated.

 There are a bunch of PEPs that have been accepted (or close), but not
 implemented.  I think these include (please correct me, so we can get
 a good list):

  http://www.python.org/peps/

  SA  308  Conditional Expressions
  SA  328  Imports: Multi-Line and Absolute/Relative
  SA  342  Coroutines via Enhanced Generators
  S   343  The with Statement
  S   353  Using ssize_t as the index type

 This one should be marked as final I believe:

   SA  341  Unifying try-except and try-finally

 n
 ___
 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/jeremy%40alum.mit.edu

___
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] Know anyone interested in a Google internship?

[Jeremy Hylton]

On 1/24/06, Guido van Rossum [EMAIL PROTECTED] wrote:
 Sorry for the plug.

 Google is looking to fill an unprecedented number of student intern
 positions this summer, at several US locations (Mountain View, Santa
 Monica, Kirkland (Wash.), and New York). If you're interested or know
 someone interested, please see
 http://www.google.com/jobs/intern.html. Candidates from outside the US
 are welcome. The perks are incredible (just ask Brett Cannon, who's
 coming back for the second year this summer :-).

 We're not just looking for software development interns -- there are
 also product management positions, and UI design and usability analyst
 positions.

 I can't guarantee that I'll be mentoring you, but if you end up using
 Python in Mountain View, I'm sure we'll be interacting quite a bit!

And I'd be happy to work with folks in New York!

Jeremy
___
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] str with base

[Jeremy Hylton]

On 1/19/06, Aahz [EMAIL PROTECTED] wrote:
 On Thu, Jan 19, 2006, Jeremy Hylton wrote:
 
  I'm not sure I believe this should be a builtin.  I think the
  threshold for new builtins ought to be nearly as high as the threshold
  for new keywords.  Or the proposer ought to make an argument about
  what the function should not go in a module.

 The way I'd put it, any function that wants to go in builtins should
 require a formal PEP.

I'm suggesting a criterion for evaluating the choice of builtin vs.
module, not making a suggestion about the process.

Jeremy
___
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] str with base

[Jeremy Hylton]

It never occured to me that str() would behave like int() for this
case.  It makes complete sense to me that a factory for numbers would
ask about the base of the number.  What would the base of a string be,
except in a few limited cases? str([1, 2], 4) doesn't make any sense. 
You might argue that I wasn't all that bright as a beginner 0.5
wink.

I think it shouldn't be changed, because the second positional
argument only works for a small number of the panoply types that can
be passed to str().  It would be fine to have a function for this
hiding somewhere, perhaps even as a method on numbers, but str() is
too generic.

Jeremy

On 1/16/06, Alex Martelli [EMAIL PROTECTED] wrote:
 Is it finally time in Python 2.5 to allow the obvious use of, say,
 str(5,2) to give '101', just the converse of the way int('101',1)
 gives 5?  I'm not sure why str has never allowed this obvious use --
 any bright beginner assumes it's there and it's awkward to explain
 why it's not!-).  I'll be happy to propose a patch if the BDFL
 blesses this, but I don't even think it's worth a PEP... it's an
 inexplicable though long-standing omission (given the argumentative
 nature of this crowd I know I'll get pushback, but I still hope the
 BDFL can Pronounce about it anyway;-).


 Alex

 ___
 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/jeremy%40alum.mit.edu

___
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] str with base

[Jeremy Hylton]

On 1/16/06, Alex Martelli [EMAIL PROTECTED] wrote:

 On Jan 16, 2006, at 8:03 PM, Jeremy Hylton wrote:
  I think it shouldn't be changed, because the second positional
  argument only works for a small number of the panoply types that can
  be passed to str().

 Identically the same situation as for int: the base argument is only
 accepted if the first argument is a str (not a float, etc).  Just the
 same way, the base argument to str will only be accepted if the first
 argument is an int (not a float, etc).

The concept of base is closely related to ints, and the base argument
is useful for a large percentage of the types that int accepts.  It is
not related to strings, in general, and applies to only one of the
types it accepts.  In one case not a float, etc. applies to a very
limited set of types, in the other case it applies to every
conceivable type (except int).

If str() were to take two argument, the analogy with int suggests it
should be an encoding, where the second argument describes how to
interpret the representation of the first (it's base 7 or it's utf-8).

Jeremy
___
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] API changes

[Jeremy Hylton]

The intent was to provide binary compatibility, but redirect all newly
linked code to the newer variants.  We did this correctly for
PyParser_SimpleParseFile and PyParser_SimpleParseString, but didn't do
it for the rest of the changed functions.  Can you file a bug report? 
(Or just fix the ones that bother you.)

We ought to update the docs, too.

Jeremy

On 1/3/06, Thomas Heller [EMAIL PROTECTED] wrote:
 The ast-branch merge apparently changed some formerly public functions
 to macros.  The two that I found out about are PyRun_SimpleString and
 PyRun_InteractiveLoop, I have not checked if there are more or not.

 This breaks apps which dynamically link at runtime to the Python dll
 (the latest py2exe does this).

 Was this change intentional, or can it be reverted?

 Thanks,

 Thomas

 ___
 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/jeremy%40alum.mit.edu

___
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] API changes

[Jeremy Hylton]

On 1/3/06, Thomas Heller [EMAIL PROTECTED] wrote:
 Jeremy Hylton [EMAIL PROTECTED] writes:
  On 1/3/06, Thomas Heller [EMAIL PROTECTED] wrote:
  The ast-branch merge apparently changed some formerly public functions
  to macros.  The two that I found out about are PyRun_SimpleString and
  PyRun_InteractiveLoop, I have not checked if there are more or not.
 
  This breaks apps which dynamically link at runtime to the Python dll
  (the latest py2exe does this).
 
  Was this change intentional, or can it be reverted?
 
  Thanks,
 
  Thomas
 

  The intent was to provide binary compatibility, but redirect all newly
  linked code to the newer variants.  We did this correctly for
  PyParser_SimpleParseFile and PyParser_SimpleParseString, but didn't do
  it for the rest of the changed functions.  Can you file a bug report?
  (Or just fix the ones that bother you.)
 
  We ought to update the docs, too.

 I'm not sure I understand the 'we did this correctly for ...'.
 PyParser_SimpleParseFile is a function in 2.4, and a macro in 2.5.

There's a function by the same name at the end of pythonrun.c. 
Nothing in the Python core should link to it, but it's still available
for third-party code.  Now we can mark PyParser_SimpleParseFile as
deprecated remove it in some future release.

Jeremy
___
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] commit of r41880 - python/trunk/Python/Python-ast.c

[Jeremy Hylton]

On 1/2/06, Neal Norwitz [EMAIL PROTECTED] wrote:
 On 1/2/06, Barry Warsaw [EMAIL PROTECTED] wrote:
  I think we have a fundamental problem with Python-ast.c and
  Python-ast.h.  These files should not be both auto-generated and checked
  into Subversion.

 I agree with the problem statement.

  The general rule should be that no file that is ever generated can be
  checked into Subversion.  Probably the right approach is to check in a
  template file that will not get removed by a distclean, and modify the
  build process to generate Python-ast.* from those template files.

 I'm not sure about your proposed solution, though.

 There's a bootstrapping issue.  Python-ast.[ch] are generated by a
 python 2.2+ script.  /f created a bug report if only 2.1 is available.

 The Python-ast.[ch] should probably not be removed by distclean.  This
 is similar to configure.  Would that make you happy?  What else would
 improve the current situation?

I think this solution is better.  It's relatively rare for people to
change the ast definition, so for most purposes these should be static
files.

Jeremy
___
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] timeout options in high-level networking modules

[Jeremy Hylton]

Yup.  I just went through a similar exercise with urllib2.  It wasn't
too hard to plumb through a different HTTPHandler that set the
timeout, but it would be much nicer as a default option.  It seems
like a 30 minute project; might fit in an odds and ends sprint.

Jeremy

On 12/22/05, Jim Fulton [EMAIL PROTECTED] wrote:

 Yesterday, I needed to make a web request in a program (actually a test)
 that could block indefinately, so I needed to set a socket timeout.
 Unfortunately, AFAICT none of urllib, urllib2, httplib provide options to set
 the timeout on the sockets they use.  I ended up having to roll my own
 code to make the request.

 It would be nice if high-level network modules, like the ones mentioned
 above, had options to provide a timeout.  (For example, urlopen could
 grow an optional timout argument.)

 Thoughts?

 If we think this is a good idea, then someone who has time could start 
 chipping
 away at it.  I'm happy to work on this *if* I can find time.  This would make
 a nice easy sprint project at PyCon too.

 Jim

 --
 Jim Fulton   mailto:[EMAIL PROTECTED]   Python Powered!
 CTO  (540) 361-1714http://www.python.org
 Zope Corporation http://www.zope.com   http://www.zope.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/jeremy%40alum.mit.edu

___
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] hashlib - faster md5/sha, adds sha256/512 support

[Jeremy Hylton]

Python 2.5 will include sha-256 and sha-512.  It will be released
sometime next year.

Jeremy

On 12/16/05, Ronald  L. Rivest [EMAIL PROTECTED] wrote:
 Hi --

 I'm curious as to the status of upgrading cryptographic
 hash function support in Python, now that md5 and sha1 are
 both clearly broken (in terms of collision-resistance).

 The consensus of researchers in this area (at least as
 expressed at the NIST Hash Function Workshop 10/31/05),
 is that SHA-256 is a good choice for the time being, but
 that research should continue, and other alternatives may
 arise from this research.  The larger SHA's also seem OK,
 but I think will have less demand...

 I'd like to see sha-256 supported in Python.  Has this
 already happened (and I didn't notice) and/or will it
 be happening soon?

 Thanks!

  Cheers,
  Ron Rivest

 P.S. Please cc your reply to me at [EMAIL PROTECTED] as well
   Thanks!


 Ronald L. Rivest
 Room 32-G692, Stata Center, MIT, Cambridge MA 02139
 Tel 617-253-5880, Email [EMAIL PROTECTED]


 ___
 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/jeremy%40alum.mit.edu

___
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] ElementTree in stdlib

[Jeremy Hylton]

On 12/14/05, M.-A. Lemburg [EMAIL PROTECTED] wrote:
  we also need to figure out how to import the bundled version; should it be
  cElementTree, xml.etree.cElementTree, or just xml.etree.ElementTree
  (which would then fallback on the Python version if cElementTree isn't
  built) ?

 If the semantics are identical I'd prefer the latter approach
 of using the faster variant if possible.

That is my preference, too.

Jeremy
___
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] Deprecate __ private (was Re: PEP 8 updates/clarifications)

[Jeremy Hylton]

On 12/12/05, Scott David Daniels [EMAIL PROTECTED] wrote:
 Jim Fulton wrote:
  Ian Bicking wrote:
  Jim Fulton wrote:
  Ian Bicking wrote:
 Private attributes should have two leading underscores, no
 trailing underscores.
 
  This conflicts with a previous suggestion Generally, double leading
  underscores should be used only to avoid name conflicts with
  attributes in classes designed to be subclassed.  Or perhaps
  private attributes needs to be better explained.
 ...
  I really really hate double underscores, but I thought I'd let some
  other people suggest stronger language first
 
  Can we officially mark __private as a mistake. Perhaps:
  - Strongly discourage it in the style guide
  - Mark it in the language reference as a deprecated feature
  - Generate deprecation warnings when it is used?
 (This might be too much.)

 Perhaps The __ name convention is designed for 'mixins'; as a means of
 enforcing private it is both ineffective and annoying.  For example,
 distutils.msvccompiler uses a bunch of instance variables which would I
 would like to access in a subclass, but are unavailable because the
 author could not imagine why I would need them.

These are really separate issues, right?  The effect of __ names is to
make a variable private to a class, because it's a right pain to
access it from any other class.  If you design a class for inheritance
and use __ names, you're deciding to keep the details of those names
private.

There is a separate question about whether the designer of
msvccompiler made the right choices about which instance variables
were private.  This issue is really separate from the naming
mechanism.  If the designer of the class didn't intent to make those
instance variables available to you, it's not the language's fault.

There are ways the language and tools could make things easier for
developers.  The debugger could know how to mangle names for us.  It
would be great to have editors/ides that could rename all the
variables if we decide to change the name to make it available to
subclasses.  I think these problems are the primary reasons I dislike
mangled names.  I can't remember how to type the names in pdb and it's
a pain to change every use of the name if I change from __var to _var.
 C++ private variables don't suffer from either of these problems. 
The visibility is separate from the name; if I change an instance
variable from private to protected, I don't have to edit existing code
to track a new name.

Jeremy
___
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] should I really have to install Python before I can build it ?

[Jeremy Hylton]

The C files are checked into subversion.  Perhaps there is some
problem with the timestamps that causes the Makefile to try to rebuild
them anyway?  I have a modern Python and I've been doing a fair amount
of development on these files; as a result, I haven't noticed a
problem.

Jeremy

On 12/12/05, Fredrik Lundh [EMAIL PROTECTED] wrote:
 looks like you need to have a recent Python version installed
 to be able to build the current trunk:

 ./Parser/asdl_c.py -h ./Include -c ./Python ./Parser/Python.asdl
 ./Parser/asdl_c.py:150: SyntaxWarning: local name 'self' in 
 'sum_with_constructors' shadows use of 'self' as global in nested scope
 'emit'
   def sum_with_constructors(self, sum, name, depth):
 ./Parser/asdl_c.py:263: SyntaxWarning: local name 'self' in 'emit_function' 
 shadows use of 'self' as global in nested scope 'emit'
   def emit_function(self, name, ctype, args, attrs, union=1):
 ./Parser/asdl_c.py:296: SyntaxWarning: local name 'self' in 'emit_body_union' 
 shadows use of 'self' as global in nested scope 'emit'
   def emit_body_union(self, name, args, attrs):
 ./Parser/asdl_c.py:305: SyntaxWarning: local name 'self' in 
 'emit_body_struct' shadows use of 'self' as global in nested scope
 'emit'
   def emit_body_struct(self, name, args, attrs):
 ./Parser/asdl_c.py:444: SyntaxWarning: local name 'self' in 'visitField' 
 shadows use of 'self' as global in nested scope 'emit'
   def visitField(self, field, name, depth, product):
 ./Parser/asdl_c.py:444: SyntaxWarning: local name 'depth' in 'visitField' 
 shadows use of 'depth' as global in nested scope 'emit'
   def visitField(self, field, name, depth, product):
 ./Parser/asdl_c.py:605: SyntaxWarning: local name 'self' in 'visitField' 
 shadows use of 'self' as global in nested scope 'emit'
   def visitField(self, field, name, depth, product):
 ./Parser/asdl_c.py:605: SyntaxWarning: local name 'depth' in 'visitField' 
 shadows use of 'depth' as global in nested scope 'emit'
   def visitField(self, field, name, depth, product):
 Traceback (most recent call last):
   File ./Parser/asdl_c.py, line 9, in ?
 import asdl
   File ./Parser/asdl.py, line 53, in ?
 class ASDLScanner(spark.GenericScanner, object):
 NameError: name 'object' is not defined
 make: *** [Include/Python-ast.h] Error 1

 (this machine has Python 2.1)

 any reason why the C files are not checked into subversion ?

 /F



 ___
 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/jeremy%40alum.mit.edu

___
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