[Python-3000] PyCon 2009 - Call for proposals

Hi folks, PyCon '09 will be opening for talk proposals shortly; see below. We'd love to have some great talks on Python 3000, so please don't be shy! Cheers, Ivan Krstić Chair, PyCon 2009 Program Committee * * * Call for proposals -- PyCo

Re: [Python-3000] Spooky behavior of dict.items() and friends

ly tells me "I'm computing something. It might be expensive, and if you call me again, I'll have to recompute." This made sense with .keys() in 2.x, but is not true in 3.0. Is there a good reason besides compatibility to keep the parentheses there? sorted(x.keys)

Re: [Python-3000] pyvm module - low level interface to Python's VM

after it was brought to his attention by, I think, PJE. -- Ivan Krstić <[EMAIL PROTECTED]> | http://radian.org ___ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mai

Re: [Python-3000] 3.0 crypto (was: Re: Solaris support in 3.0?)

ink crypto shouldn't come bundled with the language. I'm volunteering to tackle the first two, assuming those are the actual problems. Are they? -- Ivan Krstić <[EMAIL PROTECTED]> | http://radian.org ___ Python-3000 mailing list Python-3000

Re: [Python-3000] 3.0 crypto

n) LibTomCrypt code that mimicked that of pycrypto, would anyone object to getting that kind of thing into the Python source distribution? > Besides the chances are that most programmers seeing a crypto > library will misuse it and gain a false sense of security on what > they

Re: [Python-3000] 3.0 crypto

d so on. The distribution size issue can be mitigated by a reasonable choice of supported primitives. I don't think we need to ship the crypto kitchen sink with Python; we can disqualify known-broken algorithms that many libraries still ship, etc. -- Iv

[Python-3000] 3.0 crypto (was: Re: Solaris support in 3.0?)

es, and provided more than just a hash or two. Doing the work isn't a problem. Is legalese? -- Ivan Krstić <[EMAIL PROTECTED]> | http://radian.org ___ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listi

Re: [Python-3000] Lines breaking

ugh. I tried a Google code search for lang:perl split\(?\s?\/\[(simple multiple separators) lang:python \.splitlines\s?\( lang:python \.split\s?\( but the number of results seems to oscillate between 300 and 10, so that didn't help muc

Re: [Python-3000] Support for PEP 3131

including English non-natively, and unexpected bidi behavior still looks unfamiliar and confusing to me. I haven't had time to participate in this discussion though I've been following it; FWIW, I'm a loud -1 on Unicode identifiers by default for just about the exact reasons that Pi

Re: [Python-3000] Lines breaking

Guido van Rossum wrote: > What would that do? It would split on all separators in the tuple, so x.split(("\r", "\n")) would do the same thing that x.splitlines() does now. -- Ivan Krstić <[EMAIL PROTECTED]> | GPG: 0x147C722D __

Re: [Python-3000] PEP: Supporting Non-ASCII Identifiers

by saying that it's important for all Python code to read as Python code, not as "Python code that might sometimes mean something entirely different because of macros". Keyword translation would cause a similarly ugly problem, I suspect. -- Ivan Krstić <

Re: [Python-3000] Principles

rse 3.0 isn't a blank check for gratuitous breakage, but being conservative *solely* for the purpose of not breaking compatibility defeats the purpose of having a 3.0 separate from the 2.x series, IMO. -- Ivan Krstić <[EMAIL PROTECTED]> | GPG: 0x147C722D ___

Re: [Python-3000] PEP 3108: Standard Library Reorganization

Brett Cannon wrote: > "nis" -- NIS is still widely used by many people; probably premature > to remove. > > Yuck, really? Anyone else agree with this? Yes, absolutely; Bill beat me to the punch. I know of new deployments going with NIS instead of LDAP, even. -

Re: [Python-3000] Special methods and interface-based type system

rm yet, but in the meantime, thinking about these methods as system glue, staples, paperclips, or a different fastener term of your choice, might illuminate the difference further. :) -- Ivan Krstić <[EMAIL PROTECTED]> | GPG: 0x147C722D ___ Python-3000

Re: [Python-3000] Special methods and interface-based type system

asons I understand Phillip is championing `defop`, though other approaches would for example include explicit method namespaces. -- Ivan Krstić <[EMAIL PROTECTED]> | GPG: 0x147C722D ___ Python-3000 mailing list Python-3000@python.org http://mai

Re: [Python-3000] A plea for anonymous functions

*", i.e. while avoiding special-cased solutions. The LINQ special case given above won't help me in building proper multiprocessing support. Now, maybe special-cased solutions are preferred to more metaprogramming, in which case there's not much point in c

Re: [Python-3000] A plea for anonymous functions

(which was Guido's fear), just in exceedingly ugly and arbitrarily limited ways. -- Ivan Krstić <[EMAIL PROTECTED]> | GPG: 0x147C722D ___ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com

Re: [Python-3000] A plea for anonymous functions

s/ metaprogramming. Guido does not wish to make Python syntax any more programmable, however, while at the same time features like metaclasses tempt us just enough to feel the possibilities are within reach. [0] See second to last paragraph: http://mail.python.org/piperma

Re: [Python-3000] Proposal: No more standard library additions

for developers to work with, well-documented, and for which there exist better and less arcane tools than what we have now. -- Ivan Krstić <[EMAIL PROTECTED]> | GPG: 0x147C722D ___ Python-3000 mailing list Python-3000@python.org http://mail

Re: [Python-3000] Proposal: No more standard library additions

plicitly connect my thoughts. CPAN's cultural success is predicated on a generally standardized build/install/test system and package layout. -- Ivan Krstić <[EMAIL PROTECTED]> | GPG: 0x147C722D ___ Python-3000 mailing list Python-3000@python.org

Re: [Python-3000] Proposal: No more standard library additions

7;t been able to -- culturally -- create their own version of CPAN, and failing that, why they haven't copied CPAN outright. The Perl world has pretty much standardized on the "if it's out there, it's on CPAN" model, and it's one of the langua

Re: [Python-3000] Proposal: No more standard library additions

ing else?), and feels the need to remind me just how easy it is every time I use it -- when I go to type the command name. :) -- Ivan Krstić <[EMAIL PROTECTED]> | GPG: 0x147C722D ___ Python-3000 mailing list Python-3000@python.org http://mail.

Re: [Python-3000] Kill GIL? - to PEP 3099?

e what's the best I can do there. -- Ivan Krstić <[EMAIL PROTECTED]> | GPG: 0x147C722D ___ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/opti

Re: [Python-3000] Sky pie: a "var" keyword

e it. Ka-Ping, will you write a PEP? If not, I'll take it on. -- Ivan Krstić <[EMAIL PROTECTED]> | GPG: 0x147C722D ___ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://m

Re: [Python-3000] Removing __del__

od. I think Py3k > should be as lean as possible and then build-up very slowly afterwards, > emphasizing cruft-removal instead of cruft-substitution. +1, on all counts. -- Ivan Krstić <[EMAIL PROTECTED]> | GPG: 0x147C722D ___ Python-3000 mailin

Re: [Python-3000] Removing __var

Raymond Hettinger wrote: > I propose dropping the __var private name mangling trick for > double-underscores. +1. -- Ivan Krstić <[EMAIL PROTECTED]> | GPG: 0x147C722D ___ Python-3000 mailing list Python-3000@python.org http://mail.python

Re: [Python-3000] Kill GIL? - to PEP 3099?

he GIL, but providing some form of sane multiprocessing support that doesn't require everyone interested in MP to reinvent the wheel. The GIL situation and Guido's position on it seem pretty clear to me, as I've tried to indicate in prior messages.

Re: [Python-3000] Kill GIL?

in Python; if it involves diving into CPython, I'll require assistance), and ongoing maintenance of the same for the foreseeable future. -- Ivan Krstić <[EMAIL PROTECTED]> | GPG: 0x147C722D ___ Python-3000 mailing list Python-3000@python.org htt

Re: [Python-3000] Kill GIL?

out this in the next few days, and stick it in the PEP after Guido chimes in. > Since you are fired up about this now, would you consider writing a PEP > at least outlining the problem persuasively and championing one of the > (feasible) options? Sure. -- Ivan Krstić <[EMAIL PR

Re: [Python-3000] Kill GIL?

ut real-world problems, where this most often doesn't work. > But in the end, you have to realize this is all at a higher level than > we would really need to even consider for the discussion at hand. I was answering a direct question. -- Ivan Krstić <[EMAIL PROTECTED]> | GPG:

Re: [Python-3000] Kill GIL?

ock during a write (and since writes only happen at the completion of complex calculations, they generally want to use locking like that provided by brlocks in the Linux kernel). All of this is workable without SHM, but some of it gets really unwieldy. -- Ivan Krstić <[EMAIL PROTECTED]> | GPG:

Re: [Python-3000] Kill GIL?

The first option is a Pareto optimization, but having stdlib functionality flat out unavailable on some platforms might be out of the question. It'd be good to hear Guido's longer-term view on concurrency in Python. That discussion might be more appropriate on python-dev, th

Re: [Python-3000] Droping find/rfind?

and more complete support for buffers, rather than their removal. A bunch of people, myself included, want to use Python as a persistent network server. Proper support for reading into already-allocated memory, and non-copying strings are pretty indispensable for serious production use. -- Ivan Krs

Re: [Python-3000] Google Sprint Ideas

ld probably discuss here. -- Ivan Krstić <[EMAIL PROTECTED]> | GPG: 0x147C722D ___ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com