Re: [Python-Dev] 2.5 PEP
(my mails to python-dev are bouncing; guess that's what you get when you question the PSF's ability to build web sites... trying again.) Neal Norwitz wrote: > > (is the xmlplus/xmlcore issue still an issue, btw?) > > What issue are you talking about? the changes described here http://mail.python.org/pipermail/python-dev/2005-December/058710.html "I'd like to propose that a new package be created in the standard library: xmlcore." which led to this response from a pyxml maintainer: http://mail.python.org/pipermail/python-dev/2005-December/058752.html "I don't agree with the change. You just broke source compatibility between the core package and PyXML." ___ 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
[Python-Dev] Adventures with ASTs - Inline Lambda
First off, let me apologize for bringing up a topic that I am sure that
everyone is sick of: Lambda.
I broached this subject to a couple of members of this list privately,
and I got wise feedback on my suggestions which basically amounted to
"don't waste your time."
However, after having thought about this for several weeks, I came to
the conclusion that I felt so strongly about this issue that the path of
wisdom simply would not do, and I would have to choose the path of
folly. Which I did.
In other words, I went ahead and implemented it. Actually, it wasn't too
bad, it only took about an hour of reading the ast.c code and the
Grammar file (neither of which I had ever looked at before) to get the
general sense of what's going on.
So the general notion is similar to the various proposals on the Wiki -
an inline keyword which serves the function of lambda. I chose the
keyword "given" because it reminds me of math textbooks, e.g. "given x,
solve for y". And I like the idea of syntactical structures that make
sense when you read them aloud.
Here's an interactive console session showing it in action.
The first example shows a simple closure that returns the square of a
number.
>>> a = (x*x given x)
>>> a(9)
81
You can also put parens around the argument list if you like:
>>> a = (x*x given (x))
>>> a(9)
81
Same thing with two arguments, and with the optional parens:
>>> a = (x*y given x,y)
>>> a(9, 10)
90
>>> a = (x*y given (x,y))
>>> a(9, 10)
90
Yup, keyword arguments work too:
>>> a = (x*y given (x=3,y=4))
>>> a(9, 10)
90
>>> a(9)
36
>>> a()
12
Use an empty paren-list to indicate that you want to define a closure
with no arguments:
>>> a = (True given ())
>>> a()
True
Note that there are some cases where you have to use the parens around
the arguments to avoid a syntactical ambiguity:
>>> map( str(x) given x, (1, 2, 3, 4) )
File "", line 1
map( str(x) given x, (1, 2, 3, 4) )
^
SyntaxError: invalid syntax
As you can see, adding the parens makes this work:
>>> map( str(x) given (x), (1, 2, 3, 4) )
['1', '2', '3', '4']
More fun with "map":
>>> map( str(x)*3 given (x), (1, 2, 3, 4) )
['111', '222', '333', '444']
Here's an example that uses the **args syntax:
>>> a = (("%s=%s" % pair for pair in kwargs.items()) given **kwargs)
>>> list( a(color="red") )
['color=red']
>>> list( a(color="red", sky="blue") )
['color=red', 'sky=blue']
I have to say, the more I use it, the more I like it, but I'm sure that
this is just a personal taste issue. It looks a lot more natural to me
than lambda.
I should also mention that I resisted the temptation to make the 'given'
keyword an optional generator suffix as in "(a for a in l given l). As I
started working with the code, I started to realize that generators and
closures, although they have some aspects in common, are very different
beasts and should not be conflated lightly. (Plus the implementation
would have been messy. I took that as a clue :))
Anyway, if anyone wants to play around with the patch, it is rather
small - a couple of lines in Grammar, and a small new function in ast.c,
plus a few mods to other functions to get them to call it. The context
diff is less than two printed pages. I can post it somewhere if people
are interested.
Anyway, I am not going to lobby for a language change or write a PEP
(unless someone asks me to.) I just wanted to throw this out there and
see what people think of it. I definately don't want to start a flame
war, although I suspect I already have :/
Now I can stop thinking about this and go back to my TurboGears-based
Thesaurus editor :)
-- Talin
___
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] how bugfixes are handled?
Guido van Rossum wrote: > We're all volunteers here, and we get a large volume of bugs. That's obvious (note, I'm not complaining, I'm asking ,,how it works for python''). > Unfortunately, bugfixes are reviewed on a voluntary basis. > > Are you aware of the standing offer that if you review 5 bugs/patches > some of the developers will pay attention to your bug/patch? I wasn't, thanks for information. Still few questions... one of developers/commiters reviews patch and commit it? Few developers has to review single patch? Thanks, -- Arkadiusz MiśkiewiczPLD/Linux Team http://www.t17.ds.pwr.wroc.pl/~misiek/ http://ftp.pld-linux.org/ ___ 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] Adventures with ASTs - Inline Lambda
Talin wrote: > So the general notion is similar to the various proposals on the Wiki - > an inline keyword which serves the function of lambda. I chose the > keyword "given" because it reminds me of math textbooks, e.g. "given x, > solve for y". And I like the idea of syntactical structures that make > sense when you read them aloud. but that's about the only advantage you get from writing (x*x given x) instead of lambda x: x*x right ? or did I miss some subtle detail here ? > I definately don't want to start a flame war, although I suspect I already > have :/ I think most about everything has already been said wrt lambda already, but I guess we could have a little war on spelling issues ;-) ___ 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] Adventures with ASTs - Inline Lambda
On 2/16/06, Fredrik Lundh <[EMAIL PROTECTED]> wrote: > Talin wrote: > > I definately don't want to start a flame war, although I suspect I already > > have :/ > > I think most about everything has already been said wrt lambda already, > but I guess we could have a little war on spelling issues ;-) Agreed, but credit to Talin for actually implementing his suggestion. And it's nice to see that the AST makes this sort of experimentation easier. Paul. ___ 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] http://www.python.org/dev/doc/devel still available
Jeremy Hylton wrote: > 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? [...] Such as http://mail.python.org/mailman/listinfo/pydotorg-redesign ? -- Gerhard ___ 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] bytes.from_hex() [Was: PEP 332 revival in coordination with pep 349?]
Josiah Carlson wrote: > They may not be encodings of _unicode_ data, But if they're not encodings of unicode data, what business do they have being available through someunicodestring.encode(...)? Greg ___ 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] C AST to Python discussion
Brett Cannon wrote: > If the compiler was hacked on by more people I would agree with this. > But few people do This has the potential to be a self-perpetuating situation. There may be few people hacking on it now, but more people may want to in the future. Those people may look at the funky coding style and get discouraged, so there remains only few people working on it, thus apparently justifying the decision to keep the funky coding style. Whereas if there weren't any funky coding style in the first place, more potential compiler hackers might be encouraged to have a go. Also I'm still wondering why we're going to all this effort to build a whole new AST and compiler structure if the purpose isn't to *avoid* all this transformation between different representations. Greg ___ 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] from __future__ import unicode_strings?
Neil Schemenauer wrote: > On Thu, Feb 16, 2006 at 02:43:02AM +0100, Thomas Wouters wrote: >> On Wed, Feb 15, 2006 at 05:23:56PM -0800, Guido van Rossum wrote: >> from __future__ import unicode_strings >>> Didn't we have a command-line option to do this? I believe it was >>> removed because nobody could see the point. (Or am I hallucinating? >>> After several days of non-stop discussing bytes that must be >>> considered a possibility.) >> We do, and it's not been removed: the -U switch. > > As Guido alluded, the global switch is useless. A per-module switch > something that could actually useful. One nice advantage is that > you would write code that works the same with Jython (wrt to string > literals anyhow). The global switch is not useless. It's purpose is to test the standard library (or any other piece of Python code) for Unicode compatibility. Since we're not even close to such compatibility, I'm not sure how useful a per-module switch would be. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Feb 16 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 [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] PEP 338 issue finalisation (was Re: 2.5 PEP)
Guido van Rossum wrote:
> On 2/15/06, Nick Coghlan <[EMAIL PROTECTED]> wrote:
>> PEP 338 is pretty much ready to go, too - just waiting on Guido's review and
>> pronouncement on the specific API used in the latest update (his last PEP
>> parade said he was OK with the general concept, but I only posted the PEP 302
>> compliant version after that).
>
> I like the PEP and the implementation (which I downloaded from SF).
> Here are some comments in the form of diffs (attached).
>
> Do you have unit tests for everything? I believe I fixed a bug in the
> code that reads a bytecode file (it wasn't skipping the timestamp).
I haven't worked the filesystem based tests into the unit tests yet, and even
the manual tests I was using managed to leave out compiled bytecode files (as
you noticed). I'll fix that.
Given I do my testing on Linux, I probably still would have forgotten the 'rb'
mode definitions on the relevant calls to open() though. . .
> +++ pep-0338.txt (working copy)
> -The optional argument ``init_globals`` may be used to pre-populate
> +The optional argument ``init_globals`` may be a dictionary used to
> pre-populate
> the globals dictionary before the code is executed. The supplied
> dictionary will not be modified.
I just realised that anything that's a legal argument to "dict.update" will
work. I'll fix the function description in the PEP (and the docs patch as well).
> --- runpy.py Wed Feb 15 15:56:07 2006
> def get_data(self, pathname):
> ! # XXX Unfortunately PEP 302 assumes text data :-(
> ! return open(pathname).read()
Hmm.
The PEP itself requests that a string be returned from get_data(), but doesn't
require that the file be opened in text mode. Perhaps the PEP 302 emulation
should use binary mode here? Otherwise there could be strange data corruption
bugs on Windows.
> --- 337,349
>
> # This helper is needed as both the PEP 302 emulation and the
> # main file execution functions want to read compiled files
> + # XXX marshal can also raise EOFError; perhaps that should be
> + # turned into ValueError? Some callers expect ValueError.
> def _read_compiled_file(compiled_file):
> magic = compiled_file.read(4)
> if magic != imp.get_magic():
> raise ValueError("File not compiled for this Python version")
> + compiled_file.read(4) # Throw away timestamp
> return marshal.load(compiled_file)
I'm happy to convert EOFError to ValueError here if you'd prefer (using the
string representation of the EOFError as the message in the ValueError).
Or did you mean changing the behaviour in marshal itself?
> --- 392,407
> loader = _get_loader(mod_name)
> if loader is None:
> raise ImportError("No module named " + mod_name)
> + # XXX get_code() is an *optional* loader feature. Is that okay?
> code = loader.get_code(mod_name)
If the loader doesn't provide access to the code object or the source code,
then runpy can't really do anything useful with that module (e.g. if its a C
builtin module). Given that PEP 302 states that if you provide get_source()
you should also provide get_code(), this check should be sufficient to let
runpy.run_module get to everything it can handle.
A case could be made for converting the attribute error to an ImportError, I
guess. . .
> filename = _get_filename(loader, mod_name)
> if run_name is None:
> run_name = mod_name
> + # else:
> + # XXX Should we also set sys.modules[run_name] =
> sys.modules[mod_name]?
> + # I know of code that does "import __main__". It should
> probably
> + # get the substitute __main__ rather than the original __main__,
> + # if run_name != mod_name
> return run_module_code(code, init_globals, run_name,
> filename, loader, as_script)
Hmm, good point. How about a different solution, though: in run_module_code, I
could create a new module object and put it temporarily in sys.modules, and
then remove it when done (restoring the original module if necessary).
That would mean any module with code that looks up "sys.modules[__name__]"
would still work when run via runpy.run_module or runpy.run_file.
I also realised that sys.argv[0] should be restored to its original value, too.
I'd then change the "as_script" flag to "alter_sys" and have it affect both of
the above operations (and grab the import lock to avoid other import or
run_module_code operations seeing the altered version of sys.modules).
> --- 439,457
>
> Returns the resulting top level namespace dictionary
> First tries to run as a compiled file, then as a source file
> +XXX That's not the same algorithm as used by regular import;
> +if the timestamp in the compiled file is not equal to the
> +source file's mtime, the compiled file is ignored
> +(unle
Re: [Python-Dev] bytes type discussion
On 2/15/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > Adam Olsen wrote: > > Making it an error to have 8-bit str literals in 2.x would help > > educate the user that they will change behavior in 3.0 and not be > > 8-bit str literals anymore. > > You would like to ban string literals from the language? Remember: > all string literals are currently 8-bit (byte) strings. That's a rather literal interpretation of what I said. ;) What I meant was to only accept 7-bit characters, namely ascii. -- Adam Olsen, aka Rhamphoryncus ___ 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] 2.5 PEP
Neal Norwitz wrote: > On 2/15/06, Alain Poirier <[EMAIL PROTECTED]> wrote: >> - isn't the current implementation of itertools.tee (cache of previous >> generated values) incompatible with the new possibility to feed a >> generator (PEP 342) ? > > I'm not sure what you are referring to. What is the issue? The 'tee' object doesn't have a "send" method. (This is true for all of the itertools iterators, I believe). The request is misguided though - the itertools module is designed to operate on output-only iterators, not on generators that expect input via send(). Because the output values might depend on the values sent, then it makes no sense to cache them (or do most of the other things itertools does). The relevant functionality would actually make the most sense as a fork() method on generators, but PEP 342 was trying to be fairly minimalist. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ 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
[Python-Dev] Rename str/unicode to text [Was: Re: str object going in Py3K]
On 2/15/06, Guido van Rossum <[EMAIL PROTECTED]> wrote: > On 2/15/06, M.-A. Lemburg <[EMAIL PROTECTED]> wrote: > > Barry Warsaw wrote: > > > On Wed, 2006-02-15 at 18:29 +0100, M.-A. Lemburg wrote: > > > > > >> Maybe a weird idea, but why not use static methods on the > > >> bytes and str type objects for this ?! > > >> > > >> E.g. bytes.openfile(...) and unicode.openfile(...) (in 3.0 > > >> renamed to str.openfile()) > > > > > > That's also not a bad idea, but I'd leave off one or the other of the > > > redudant "open" and "file" parts. E.g. bytes.open() and unicode.open() > > > seem fine to me (we all know what 'open' means, right? :). > > > > Thinking about it, I like your idea better (file.bytes() > > and file.text()). > > This is better than making it a static/class method on file (which has > the problem that it might return something that's not a file at all -- > file is a particular stream implementation, there may be others) but I > don't like the tight coupling it creates between a data type and an > I/O library. I still think that having global (i.e. built-in) factory > functions for creating various stream types makes the most sense. While we're at it, any chance of renaming str/unicode to text in 3.0? It's a MUCH better name, as evidenced by the opentext/openbytes names. str is just some odd C-ism. Obviously it's a form of gratuitous breakage, but I think the long term benefits are enough that we need to be *sure* that the breakage would be too much before we discount it. This seems the right time to discuss that. (And no, I'm not suggesting any special semantics for text. It's just the name I want.) str literal -> text literal unicode literal -> text literal text file -> text file (duh!) tutorial section called "Strings" -> tutorial section called "Text" Documentation Strings -> Documentation Text String Pattern Matching -> Text Pattern Matching String Services -> Text Services. Actually this is a problem. struct should be used on bytes, not unicode/text. textwrap -> textwrap stringprep -> textprep? Doesn't seem like a descriptive name linecache "Random access to text lines" gettext (not getstring!) -- Adam Olsen, aka Rhamphoryncus ___ 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] Adventures with ASTs - Inline Lambda
On Feb 16, 2006, at 2:05 AM, Talin wrote: > > Anyway, if anyone wants to play around with the patch, it is rather > small - a couple of lines in Grammar, and a small new function in > ast.c, > plus a few mods to other functions to get them to call it. The context > diff is less than two printed pages. I can post it somewhere if people > are interested. > Please submit a SourceForge patch so others can play with it! -Barry ___ 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] Adventures with ASTs - Inline Lambda
Paul Moore wrote: > On 2/16/06, Fredrik Lundh <[EMAIL PROTECTED]> wrote: >> Talin wrote: >>> I definately don't want to start a flame war, although I suspect I already >>> have :/ >> I think most about everything has already been said wrt lambda already, >> but I guess we could have a little war on spelling issues ;-) > > Agreed, but credit to Talin for actually implementing his suggestion. > And it's nice to see that the AST makes this sort of experimentation > easier. Aye to both of those comments (and the infix spelling really is kind of pretty). Who knows, maybe Guido will decide he wants to change the spelling some day. Probably only if the sky fell on him or something, though ;) Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ 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] C AST to Python discussion
On 2/16/06, Greg Ewing <[EMAIL PROTECTED]> wrote: > Whereas if there weren't any funky coding style in the > first place, more potential compiler hackers might be > encouraged to have a go. I'm trying to make the code simple. The style of code is different than other parts of Python, but a compiler is different than a bytecode engine or implementations of basic types. Different problem domains lead to different program structure. > Also I'm still wondering why we're going to all this effort > to build a whole new AST and compiler structure if the > purpose isn't to *avoid* all this transformation between > different representations. The goal is to get the right representation for the problem. It was harder to understand and modify the compiler when it worked on the concrete parse trees. The compiler now has a couple of abstractions that are well suited to particular phases of compilation. 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] from __future__ import unicode_strings?
On Thu, 16 Feb 2006 11:24:35 +0100, "M.-A. Lemburg" <[EMAIL PROTECTED]> wrote: >Neil Schemenauer wrote: >> On Thu, Feb 16, 2006 at 02:43:02AM +0100, Thomas Wouters wrote: >>> On Wed, Feb 15, 2006 at 05:23:56PM -0800, Guido van Rossum wrote: >>> > from __future__ import unicode_strings Didn't we have a command-line option to do this? I believe it was removed because nobody could see the point. (Or am I hallucinating? After several days of non-stop discussing bytes that must be considered a possibility.) >>> We do, and it's not been removed: the -U switch. >> >> As Guido alluded, the global switch is useless. A per-module switch >> something that could actually useful. One nice advantage is that >> you would write code that works the same with Jython (wrt to string >> literals anyhow). > >The global switch is not useless. It's purpose is to test the >standard library (or any other piece of Python code) for Unicode >compatibility. > >Since we're not even close to such compatibility, I'm not sure >how useful a per-module switch would be. Just what Neil suggested: developers writing new code benefit from having the behavior which will ultimately be Python's default, rather than the behavior that is known to be destined for obsolescence. Being able to turn this on per-module is useful for the same reason the rest of the future system is useful on a per-module basis. It's easier to convert things incrementally than monolithicly. Jean-Paul ___ 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] PEP 338 issue finalisation (was Re: 2.5 PEP)
On 2/16/06, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
> > Do you have unit tests for everything? I believe I fixed a bug in the
> > code that reads a bytecode file (it wasn't skipping the timestamp).
[Hey, I thought I sent that just to you. Is python-dev really
interested in this?]
> I haven't worked the filesystem based tests into the unit tests yet, and even
> the manual tests I was using managed to leave out compiled bytecode files (as
> you noticed). I'll fix that.
>
> Given I do my testing on Linux, I probably still would have forgotten the 'rb'
> mode definitions on the relevant calls to open() though. . .
But running the unit tests on Windows would have revealed the problem.
> > +++ pep-0338.txt (working copy)
> > -The optional argument ``init_globals`` may be used to pre-populate
> > +The optional argument ``init_globals`` may be a dictionary used to
> > pre-populate
> > the globals dictionary before the code is executed. The supplied
> > dictionary will not be modified.
>
> I just realised that anything that's a legal argument to "dict.update" will
> work. I'll fix the function description in the PEP (and the docs patch as
> well).
I'm not sure that's a good idea -- you'll never be able to switch to a
different implementation then.
> > --- runpy.py Wed Feb 15 15:56:07 2006
> > def get_data(self, pathname):
> > ! # XXX Unfortunately PEP 302 assumes text data :-(
> > ! return open(pathname).read()
>
> Hmm.
>
> The PEP itself requests that a string be returned from get_data(), but doesn't
> require that the file be opened in text mode. Perhaps the PEP 302 emulation
> should use binary mode here? Otherwise there could be strange data corruption
> bugs on Windows.
But PEP 302 shows as its only example reading from a file with a .txt
extension. Adding spurious \r characters is also data corruption. We
should probably post to python-dev a request for clarification of PEP
302, but in the mean time I vote for text mode.
> > --- 337,349
> >
> > # This helper is needed as both the PEP 302 emulation and the
> > # main file execution functions want to read compiled files
> > + # XXX marshal can also raise EOFError; perhaps that should be
> > + # turned into ValueError? Some callers expect ValueError.
> > def _read_compiled_file(compiled_file):
> > magic = compiled_file.read(4)
> > if magic != imp.get_magic():
> > raise ValueError("File not compiled for this Python version")
> > + compiled_file.read(4) # Throw away timestamp
> > return marshal.load(compiled_file)
>
> I'm happy to convert EOFError to ValueError here if you'd prefer (using the
> string representation of the EOFError as the message in the ValueError).
>
> Or did you mean changing the behaviour in marshal itself?
No -- the alternative is to catch EOFError in _read_compiled_file()'s
caller, but that seems worse. You should check marshal.c if it can
raise any *other* errors (perhaps OverflowError?).
Also, *perhaps* it makes more sense to return None instead of raising
ValueError? Since you're always catching it? (Or are you?)
> > --- 392,407
> > loader = _get_loader(mod_name)
> > if loader is None:
> > raise ImportError("No module named " + mod_name)
> > + # XXX get_code() is an *optional* loader feature. Is that okay?
> > code = loader.get_code(mod_name)
>
> If the loader doesn't provide access to the code object or the source code,
> then runpy can't really do anything useful with that module (e.g. if its a C
> builtin module). Given that PEP 302 states that if you provide get_source()
> you should also provide get_code(), this check should be sufficient to let
> runpy.run_module get to everything it can handle.
OK. But a loader could return None from get_code() -- do you check for
that? (I don't have the source handy here.)
> A case could be made for converting the attribute error to an ImportError, I
> guess. . .
I'm generally not keen on that; leave it.
> > filename = _get_filename(loader, mod_name)
> > if run_name is None:
> > run_name = mod_name
> > + # else:
> > + # XXX Should we also set sys.modules[run_name] =
> > sys.modules[mod_name]?
> > + # I know of code that does "import __main__". It should
> > probably
> > + # get the substitute __main__ rather than the original
> > __main__,
> > + # if run_name != mod_name
> > return run_module_code(code, init_globals, run_name,
> > filename, loader, as_script)
>
> Hmm, good point. How about a different solution, though: in run_module_code, I
> could create a new module object and put it temporarily in sys.modules, and
> then remove it when done (restoring the original module if necessary).
That might work too.
What happens when you execute "foo.py" as __main__ and then (perhaps
indirectly) something does "import
Re: [Python-Dev] Adventures with ASTs - Inline Lambda
Paul Moore wrote: > > I think most about everything has already been said wrt lambda already, > > but I guess we could have a little war on spelling issues ;-) > > Agreed, but credit to Talin for actually implementing his suggestion. > And it's nice to see that the AST makes this sort of experimentation > easier. absolutely! +1 on experimentation! ___ 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] 2.5 PEP
> > (is the xmlplus/xmlcore issue still an issue, btw?) > > What issue are you talking about? the changes described here http://mail.python.org/pipermail/python-dev/2005-December/058710.html "I'd like to propose that a new package be created in the standard library: xmlcore." which led to this response from a pyxml maintainer: http://mail.python.org/pipermail/python-dev/2005-December/058752.html "I don't agree with the change. You just broke source compatibility between the core package and PyXML." ___ 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] [Python-projects] AST in Python 2.5
On Wed, Feb 15, 2006 at 09:40:17PM -0800, Neal Norwitz wrote: > I'm not sure if anyone here is following the AST discussion on > python-dev, but it would be great if you had any input. pylint is a > pretty big consumer of the compiler module and the decisions with > respect to the AST could impact you. > > http://mail.python.org/pipermail/python-dev/2006-February/060994.html We will jump in with better comments, but I just wanted to make sure you knew about: http://www.logilab.org/projects/astng and the work being done in PyPy: http://codespeak.net/pypy/dist/pypy/doc/parser.html http://codespeak.net/pypy/dist/pypy/module/recparser/ http://codespeak.net/pypy/dist/pypy/doc/interpreter.html http://codespeak.net/pypy/dist/pypy/interpreter/astcompiler/ Here is a bit from our EU reports that is about Workpackage 10 "Aspects and Contracts in Python": WP10 Status === Extend language with aspects and contracts * researched how other languages do it (AspectJ, HyperJ, AspectS, etc.) * started allowing AST manipulation (for weaving code and function calls) * started allowing grammar manipulation (for experimenting with syntax) WP10 Status (cont.) === AST and grammar manipulation * needed for both WP9 and WP10 * AST nodes are exposed at application-level and a compiler hook * allows to modify the AST at compile-time * syntax can be modified at run-time, but still limited because grammar objects are not fully exposed at application-level WP10 Status (cont.) === AST manipulation example:: 3 + 3 6 from parser import install_compiler_hook from hooks import _3becomes2 install_compiler_hook(_3becomes2) 3 + 3 4 -- Nicolas Chauvat logilab.fr - services en informatique avancée et gestion de connaissances ___ 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] Adventures with ASTs - Inline Lambda
Paul Moore wrote: > > > I definately don't want to start a flame war, although I suspect I already > > > have :/ > > > > I think most about everything has already been said wrt lambda already, > > but I guess we could have a little war on spelling issues ;-) > > Agreed, but credit to Talin for actually implementing his suggestion. > And it's nice to see that the AST makes this sort of experimentation > easier. absolutely! +1 for experimentation. ___ 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] nice()
Smith wrote: > Everyone knows that fp numbers must be compared with caution, but > there is a void in the relative-error department for exercising such > caution, thus the proposal for something like 'areclose'. The problem > with areclose(), however, is that it only solves one part of the > problem that needs to be solved if two fp's *are* going to be > compared: if you are going to check if a < b you would need to do > something like > > not areclose(a,b) and a < b -1 This kind of function, at best, delays the newbie pain of learning about binary floating point very slightly. No matter how you set your test, I can make a pathological case which will catch at the boundary. The standard deviation formula; the area of triangle formula which fails on slivers; ill-conditioned linear equations--the examples are endless which can trip up newbies. On the other hand, people who do care about accurate numerical analysis will not trust that the people who wrote the library really had enough numerical sophistication and will simply rewrite the test *anyhow*. The "best" solution would be to optimize the Decimal module into something sufficiently fast that binary floating point goes away by default in Python. A nice reference about binary floating point is: "What Every Computer Scientist Should Know About Floating-Point Arithmetic" by David Goldberg (available *everywhere*) For truly pedantic details about the gory nastiness of binary floating point, see William Kahan's homepage at Berkeley: http://www.cs.berkeley.edu/~wkahan/ -a ___ 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] from __future__ import unicode_strings?
Giovanni Bajo wrote: > Thomas Wouters <[EMAIL PROTECTED]> wrote: > from __future__ import unicode_strings >>> Didn't we have a command-line option to do this? I believe it was >>> removed because nobody could see the point. (Or am I hallucinating? >>> After several days of non-stop discussing bytes that must be >>> considered a possibility.) >> We do, and it's not been removed: the -U switch. > > > It's not in the output of "python -h", though. Is it secret or what? Yes. We removed it from the help output to not confuse users who are not aware of the fact that this is an experimental switch. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Feb 16 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 [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] from __future__ import unicode_strings?
Jean-Paul Calderone wrote: > On Thu, 16 Feb 2006 11:24:35 +0100, "M.-A. Lemburg" <[EMAIL PROTECTED]> wrote: >> Neil Schemenauer wrote: >>> On Thu, Feb 16, 2006 at 02:43:02AM +0100, Thomas Wouters wrote: On Wed, Feb 15, 2006 at 05:23:56PM -0800, Guido van Rossum wrote: >> from __future__ import unicode_strings > Didn't we have a command-line option to do this? I believe it was > removed because nobody could see the point. (Or am I hallucinating? > After several days of non-stop discussing bytes that must be > considered a possibility.) We do, and it's not been removed: the -U switch. >>> As Guido alluded, the global switch is useless. A per-module switch >>> something that could actually useful. One nice advantage is that >>> you would write code that works the same with Jython (wrt to string >>> literals anyhow). >> The global switch is not useless. It's purpose is to test the >> standard library (or any other piece of Python code) for Unicode >> compatibility. >> >> Since we're not even close to such compatibility, I'm not sure >> how useful a per-module switch would be. > > Just what Neil suggested: developers writing new code benefit from having the > behavior which will ultimately be Python's default, rather than the behavior > that is known to be destined for obsolescence. > > Being able to turn this on per-module is useful for the same reason the rest > of the future system is useful on a per-module basis. It's easier to convert > things incrementally than monolithicly. Sure, but in this case the option would not only affect the module you define it in, but also all other code that now gets Unicode objects instead of strings as a result of the Unicode literals defined in these modules. It is rather likely that you'll start hitting Unicode-related compatibility bugs in the standard lib more often than you'd like. It's usually better to switch to Unicode in a controlled manner: not by switching all literals to Unicode, but only some, then test things, then switch over some more, etc. This can be done by prepending the literal with the u"" modifier. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Feb 16 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 [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] bytes type discussion
Barry Warsaw wrote: > We know at least there will never be a 2.10, so I think we still have > time. because there's no way to count to 10 if you only have one digit? we used to think that back when the gas price was just below 10 SEK/L, but they found a way... ___ 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] str object going in Py3K
On Feb 15, 2006, at 20:06, Greg Ewing wrote: > Barry Warsaw wrote: > >> If we go with two functions, I'd much rather hang them off of the >> file >> type object then add two new builtins. I really do think >> file.bytes() >> and file.text() (a.k.a. open.bytes() and open.text()) is better than >> opentext() or openbytes(). > > I'm worried about feeping creaturism of the file type > here. To my mind, the file type already has too many > features, and this hinders code that wants to define > its own file-like objects. > > In 3.0 I'd like to see the file type reduced to having > as simple an interface as possible (basically just > read/write) and all other stuff (readlines, text codecs, > etc.) implemented as wrappers around it. I'd like to put my 2 cents in a agree with Greg here. Implementing a "complete" file-like object has come to be something of a pain. Perhaps we can do something akin to UserDict -- perhaps UserTextFile and UserBinaryFile? It would be nice if it could handle the default implementation of everything but read and write. Thanks, -Shane ___ 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] PEP 338 issue finalisation (was Re: 2.5 PEP)
On 2/16/06, Guido van Rossum <[EMAIL PROTECTED]> wrote: > On 2/16/06, Nick Coghlan <[EMAIL PROTECTED]> wrote: > > The PEP itself requests that a string be returned from get_data(), but > > doesn't > > require that the file be opened in text mode. Perhaps the PEP 302 emulation > > should use binary mode here? Otherwise there could be strange data > > corruption > > bugs on Windows. > > But PEP 302 shows as its only example reading from a file with a .txt > extension. Adding spurious \r characters is also data corruption. We > should probably post to python-dev a request for clarification of PEP > 302, but in the mean time I vote for text mode. FWIW, the .txt example was just a toy example. I'd say that binary mode makes sense, as I can imagine using the get_data interface to load image files, for example. It makes getting text files a bit harder (you have to munge CRLF manually) but at least you have the *option* of getting binary files. On reflection, get_data should probably have been given a mode argument. But given that it didn't, binary seems safest. OTOH, I don't know who actually *uses* get_data for real (PJE, for eggs? py2exe?). Their opinions are likely to be of more importance. On the third hand, doing whatever the zipimport module does is likely to be right, as that's the key bit of prior art. Regardless, the PEP should be clarified. I'll make the change once agreement is reached. Paul. ___ 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] 2.5 - I'm ok to do release management
[Anthony Baxter] > I'm still catching up on the hundreds of python-dev messages from the > last couple of days, but a quick note first that I'm ok to do release > management for 2.5 I, for one, am delighted to see that Australian millionaires don't give up tech work after winning an Olympic gold medal. Congratulations to Anthony on his! I didn't even know that Human-Kangaroo Doubles Luge was a sport until last night. Damn gutsy move letting the roo take top position, and I hope to see more bold thinking like that after Anthony's ribs heal. ___ 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] 2.5 - I'm ok to do release management
On 2/15/06, Anthony Baxter <[EMAIL PROTECTED]> wrote: > I'm still catching up on the hundreds of python-dev messages from the > last couple of days, but a quick note first that I'm ok to do release > management for 2.5 Thanks! While catching up, yuo can ignore the bytes discussion except for Neil Schemenauer's proto-pep. :-) -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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] 2.5 PEP
Fredrik Lundh wrote: > http://mail.python.org/pipermail/python-dev/2005-December/058752.html > > "I don't agree with the change. You just broke source compatibility > between the core package and PyXML." I'm still unhappy with that change, and still nobody has told me how to maintain PyXML so that it can continue to work both for 2.5 and for 2.4. Regards, Martin ___ 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] from __future__ import unicode_strings?
On Thu, 16 Feb 2006 16:29:40 +0100, "M.-A. Lemburg" <[EMAIL PROTECTED]> wrote: >Jean-Paul Calderone wrote: >> On Thu, 16 Feb 2006 11:24:35 +0100, "M.-A. Lemburg" <[EMAIL PROTECTED]> >> wrote: >>> Neil Schemenauer wrote: On Thu, Feb 16, 2006 at 02:43:02AM +0100, Thomas Wouters wrote: > On Wed, Feb 15, 2006 at 05:23:56PM -0800, Guido van Rossum wrote: > >>> from __future__ import unicode_strings >> Didn't we have a command-line option to do this? I believe it was >> removed because nobody could see the point. (Or am I hallucinating? >> After several days of non-stop discussing bytes that must be >> considered a possibility.) > We do, and it's not been removed: the -U switch. As Guido alluded, the global switch is useless. A per-module switch something that could actually useful. One nice advantage is that you would write code that works the same with Jython (wrt to string literals anyhow). >>> The global switch is not useless. It's purpose is to test the >>> standard library (or any other piece of Python code) for Unicode >>> compatibility. >>> >>> Since we're not even close to such compatibility, I'm not sure >>> how useful a per-module switch would be. >> >> Just what Neil suggested: developers writing new code benefit from having >> the behavior which will ultimately be Python's default, rather than the >> behavior that is known to be destined for obsolescence. >> >> Being able to turn this on per-module is useful for the same reason the rest >> of the future system is useful on a per-module basis. It's easier to >> convert things incrementally than monolithicly. > >Sure, but in this case the option would not only affect the module >you define it in, but also all other code that now gets Unicode >objects instead of strings as a result of the Unicode literals >defined in these modules. This is precisely correct. It is also exactly parallel to the only other __future__ import which changes any behavior. Personally, I _also_ like future division. Is it generally considered to have been a mistake? > >It is rather likely that you'll start hitting Unicode-related >compatibility bugs in the standard lib more often than you'd >like. You can guess this. I'll guess that it isn't the case. And who's to say how often I'd like that to happen, anyway? :) Anyone who's afraid that will happen can avoid using the import. Voila, problem solved. > >It's usually better to switch to Unicode in a controlled manner: >not by switching all literals to Unicode, but only some, then >test things, then switch over some more, etc. There's nothing uncontrolled about this proposed feature, so this statement doesn't hold any meaning. > >This can be done by prepending the literal with the u"" modifier. > Anyone who is happier converting one string literal at a time can do this. Anyone who would rather convert a module at a time can use the future import. Jean-Paul ___ 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
[Python-Dev] Proposal: defaultdict
A bunch of Googlers were discussing the best way of doing the following (a common idiom when maintaining a dict of lists of values relating to a key, sometimes called a multimap): if key not in d: d[key] = [] d[key].append(value) An alternative way to spell this uses setdefault(), but it's not very readable: d.setdefault(key, []).append(value) and it also suffers from creating an unnecessary list instance. (Timings were inconclusive; the approaches are within 5-10% of each other in speed.) My conclusion is that setdefault() is a failure -- it was a well-intentioned construct, but doesn't actually create more readable code. Google has an internal data type called a DefaultDict which gets passed a default value upon construction. Its __getitem__ method, instead of raising KeyError, inserts a shallow copy (!) of the given default value into the dict when the value is not found. So the above code, after d = DefaultDict([]) can be written as simply d[key].append(value) Note that of all the possible semantics for __getitem__ that could have produced similar results (e.g. not inserting the default in the underlying dict, or not copying the default value), the chosen semantics are the only ones that makes this example work. Over lunch with Alex Martelli, he proposed that a subclass of dict with this behavior (but implemented in C) would be a good addition to the language. It looks like it wouldn't be hard to implement. It could be a builtin named defaultdict. The first, required, argument to the constructor should be the default value. Remaining arguments (even keyword args) are passed unchanged to the dict constructor. Some more design subtleties: - "key in d" still returns False if the key isn't there - "d.get(key)" still returns None if the key isn't there - "d.default" should be a read-only attribute giving the default value Feedback? -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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] str object going in Py3K
On Wed, 15 Feb 2006 21:59:55 -0800, Alex Martelli <[EMAIL PROTECTED]> wrote:
>
>On Feb 15, 2006, at 9:51 AM, Barry Warsaw wrote:
>
>> On Wed, 2006-02-15 at 09:17 -0800, Guido van Rossum wrote:
>>
>>> Regarding open vs. opentext, I'm still not sure. I don't want to
>>> generalize from the openbytes precedent to openstr or openunicode
>>> (especially since the former is wrong in 2.x and the latter is wrong
>>> in 3.0). I'm tempting to hold out for open() since it's most
>>> compatible.
>>
>> If we go with two functions, I'd much rather hang them off of the file
>> type object then add two new builtins. I really do think file.bytes()
>> and file.text() (a.k.a. open.bytes() and open.text()) is better than
>> opentext() or openbytes().
>
>I agree, or, MAL's idea of bytes.open() and unicode.open() is also
>good. My fondest dream is that we do NOT have an 'open' builtin
>which has proven to be very error-prone when used in Windows by
>newbies (as evidenced by beginner errors as seen on c.l.py, the
>python-help lists, and other venues) -- defaulting 'open' to text is
>errorprone, defaulting it to binary doesn't seem the greatest idea
>either, principle "when in doubt, resist the temptation to guess"
>strongly suggests not having 'open' as a built-in at all. (And
>namemangling into openthis and openthat seems less Pythonic to me
>than exploiting namespaces by making structured names, either
>this.open and that.open or open.this and open.that). IOW, I entirely
>agree with Barry and Marc Andre.
>
FWIW, I'd vote for file.text and file.bytes
I don't like bytes.open or unicode.open because I think
types in general should not know about I/O (IIRC Guido said that, so pay
attention ;-)
Especially unicode.
E.g., why should unicode pull in a whole wad of I/O-related code if the user
is only using it as intermediary in some encoding change between low level
binary
input and low level binary output? E.g., consider what you could do with one
statement like (untested)
s_str.translate(table, delch).encode('utf-8')
especially if you didn't have to introduce a phony latin-1 decoding and write
it as (untested)
s_str.translate(table, delch).decode('latin-1').encode('utf-8') # use
str.translate
or
s_str.decode('latin-1').translate(mapping).encode('utf-8') # use
unicode.translate also for delch
to avoid exceptions if you have non-ascii in your s_str translation
It seems s_str.translate(table, delchars) wants to convert the s_str to unicode
if table is unicode, and then use unicode.translate (which bombs on delchars!)
instead
of just effectively defining str.translate as
def translate(self, table, deletechars=None):
return ''.join(table[ord(x)] for x in self
if deletechars is None or x not in deletechars)
IMO, if you want unicode.translate, then write unicode(s_str).translate and use
that.
Let str.translate just use the str ords, so simple custom decodes can be
written without
the annoyance of
UnicodeDecodeError: 'ascii' codec can't decode byte 0xf6 in position 3:
ordinal not in range(128)
Can we change this? Or what am I missing? I certainly would like to miss
the above message for str.translate :-(
BTW This would also allow taking advantage of features of both translates if
desired, e.g. by
s_str.translate(unichartable256,
strdelchrs).translate(uniord_to_ustr_mapping).
(e.g., the latter permits single to multiple-character substitution)
This makes me think a translate method for bytes would be good for py3k (on
topic ;-)
It it is just too handy a high speed conversion goodie to forgo IMO.
___
BTW, ISTM that it would be nice to have a
chunking-iterator-wrapper-returning-method
(as opposed to buffering specification) for file.bytes, so you could plug in
file.bytes('path').chunk(1) # maybe keyword opts for simple common record
chunking also?
in places where you might now have to have (untested)
(ord(x) for x in iter(lambda f=open('path','rb'):f.read(1)) if x)
or write a helper like
def by_byte_ords(path, bufsize=8192):
f = open(path, 'rb')
buf = f.read(bufsize)
while buf:
for x in buf: yield ord(x)
buf = f.read(bufsize)
and plug in
by_byte_ords(path)
___
BTW, bytes([]) would presumably be the file.bytes EOF?
Regards,
Bengt Richter
___
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: defaultdict
Guido van Rossum wrote: > Over lunch with Alex Martelli, he proposed that a subclass of dict > with this behavior (but implemented in C) would be a good addition to > the language. It looks like it wouldn't be hard to implement. It could > be a builtin named defaultdict. The first, required, argument to the > constructor should be the default value. Remaining arguments (even > keyword args) are passed unchanged to the dict constructor. > > Feedback? On behalf of everyone who has answered this question on c.l.py, may I say WOOHOO! FWIW, my usual spelling is: try: v = d[key] except: v = d[key] = value which breaks the principle of "write it once". Tim Delaney ___ 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: defaultdict
Guido van Rossum wrote: > The first, required, argument to the > constructor should be the default value. I'd like to suggest that this argument be a function for creating default values, rather than an actual default value. This would avoid any confusion over exactly how the default value is copied. (Shallow or deep? How deep?) In an earlier discussion it was pointed out that this would be no less convenient for many common use cases, e.g. in your example, d = defaultdict(list) Also I'm not sure about the name "defaultdict". When I created a class like this recently, I called it an "autodict" (i.e. a dict that automatically extends itself with new entries). And perhaps the value should be called an "initial value" rather than a default value, to more strongly suggest that it becomes a permanent part of the dict. Greg ___ 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] str object going in Py3K
Guido van Rossum wrote: > On 2/15/06, Alex Martelli <[EMAIL PROTECTED]> wrote: >> I agree, or, MAL's idea of bytes.open() and unicode.open() is also >> good. > > No, the bytes and text data types shouldn't have to be tied to the I/O > system. (The latter tends to evolve at a much faster rate so should be > isolated.) > >> My fondest dream is that we do NOT have an 'open' builtin >> which has proven to be very error-prone when used in Windows by >> newbies (as evidenced by beginner errors as seen on c.l.py, the >> python-help lists, and other venues) -- defaulting 'open' to text is >> errorprone, defaulting it to binary doesn't seem the greatest idea >> either, principle "when in doubt, resist the temptation to guess" >> strongly suggests not having 'open' as a built-in at all. > > Bill Janssen has expressed this sentiment too. But this is because > open() *appears* to work for both types to Unix programmers. If open() > is *only* usable for text data, even Unix programmers will be using > openbytes() from the start. All the variations aside: What will be the explicit way to open a file in bytes mode and in text mode (I for one would like to move away from open() completely as well) ? Will we have a single file type with two different modes or two different types ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Feb 16 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 [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] Rename str/unicode to text [Was: Re: str object goingin Py3K]
Adam Olsen wrote: > While we're at it, any chance of renaming str/unicode to text in 3.0? > It's a MUCH better name, as evidenced by the opentext/openbytes names. > str is just some odd C-ism. > > Obviously it's a form of gratuitous breakage, but I think the long > term benefits are enough that we need to be *sure* that the breakage > would be too much before we discount it. it's a very common variable name... ___ 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] str object going in Py3K
On 2/15/06, Alex Martelli <[EMAIL PROTECTED]> wrote: > I agree, or, MAL's idea of bytes.open() and unicode.open() is also > good. No, the bytes and text data types shouldn't have to be tied to the I/O system. (The latter tends to evolve at a much faster rate so should be isolated.) > My fondest dream is that we do NOT have an 'open' builtin > which has proven to be very error-prone when used in Windows by > newbies (as evidenced by beginner errors as seen on c.l.py, the > python-help lists, and other venues) -- defaulting 'open' to text is > errorprone, defaulting it to binary doesn't seem the greatest idea > either, principle "when in doubt, resist the temptation to guess" > strongly suggests not having 'open' as a built-in at all. Bill Janssen has expressed this sentiment too. But this is because open() *appears* to work for both types to Unix programmers. If open() is *only* usable for text data, even Unix programmers will be using openbytes() from the start. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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] Rename str/unicode to text [Was: Re: str object going in Py3K]
On 2/16/06, Adam Olsen <[EMAIL PROTECTED]> wrote: > While we're at it, any chance of renaming str/unicode to text in 3.0? > It's a MUCH better name, as evidenced by the opentext/openbytes names. > str is just some odd C-ism. > > Obviously it's a form of gratuitous breakage, but I think the long > term benefits are enough that we need to be *sure* that the breakage > would be too much before we discount it. This seems the right time to > discuss that. I'm +/-0 on this. ABC used text. In almost every other currently popular language it's called string. But the advantage of text is that it's not an abbreviation, and it reinforces the notion that it's not binary data. "Binary string" is a common colloquialism; "binary text" is an oxymoron. Mechanical conversion of code using 'str' (or 'unicode') to use 'text' seems simply enough. OTOH, even if we didn't rename str/unicode to text, opentext would still be a good name for the function that opens a text file. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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] str object going in Py3K
Greg Ewing wrote: > Another thought -- what is going to happen to os.open? > Will it change to return bytes, or will there be a new > os.openbytes? Nit-pickingly: os.open will continue to return integers. I think it should return OS handles on Windows, instead of C library handles. (also notice that this has nothing to do with stdio: os.open does not use stdio; this is POSIX open). Regards, Martin ___ 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
[Python-Dev] Test failures in test_timeout
I'm seeing spurious test failures in test_timeout, on my own workstation and
on macteagle.python.org (now that it crashes less; Apple sent over some new
memory.) The problem is pretty simple: both macteagle and my workstation
live too closely, network-wise, to www.python.org:
class TimeoutTestCase(unittest.TestCase):
[...]
def setUp(self):
[...]
self.addr_remote = ('www.python.org', 80)
[...]
def testConnectTimeout(self):
# Test connect() timeout
_timeout = 0.001
self.sock.settimeout(_timeout)
_t1 = time.time()
self.failUnlessRaises(socket.error, self.sock.connect,
self.addr_remote)
In other words, the test fails because www.python.org responds too quickly.
The test on my workstation only fails occasionally, but I do expect
macteagle's failure to be more common (since it's connected to
www.python.org through (literally) a pair of gigabit switches, whereas my
workstation has to pass through a few more switches, two Junipers and some
dark fiber.) Lowering the timeout has no effect, as far as I can tell, which
is probably a granularity issue.
I'm thinking that it could probably try to connect to a less reliable
website, but that's just moving the problem around (and possibly harassing
an unsuspecting website, particularly around release-time.) Perhaps the test
should try to connect to a known unconnecting site, like a firewalled port
on www.python.org? Not something that refuses connections, just something
that times out.
--
Thomas Wouters <[EMAIL PROTECTED]>
Hi! I'm a .signature virus! copy me into your .signature file to help me spread!
___
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] bytes.from_hex() [Was: PEP 332 revival in coordination with pep 349?]
Greg Ewing <[EMAIL PROTECTED]> wrote: > > Josiah Carlson wrote: > > > They may not be encodings of _unicode_ data, > > But if they're not encodings of unicode data, what > business do they have being available through > someunicodestring.encode(...)? I had always presumed that bytes objects are going to be able to be a source for encode AND decode, like current non-unicode strings are able to be today. In that sense, if I have a bytes object which is an encoding of rot13, hex, uu, etc., or I have a bytes object which I would like to be in one of those encodings, I should be able to do b.encode(...) or b.decode(...), given that 'b' is a bytes object. Are 'encodings' going to become a mechanism to encode and decode _unicode_ strings, rather than a mechanism to encode and decode _text and data_ strings? That would seem like a backwards step to me, as the email package would need to package their own base-64 encode/decode API and implementation, and similarly for any other package which uses any one of the encodings already available. - Josiah ___ 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] Adventures with ASTs - Inline Lambda
Talin wrote:
> First off, let me apologize for bringing up a topic that I am sure that
> everyone is sick of: Lambda.
>
> I broached this subject to a couple of members of this list privately,
> and I got wise feedback on my suggestions which basically amounted to
> "don't waste your time."
>
> However, after having thought about this for several weeks, I came to
> the conclusion that I felt so strongly about this issue that the path of
> wisdom simply would not do, and I would have to choose the path of
> folly. Which I did.
>
Thereby proving the truth of the old Scottish adage "The better the
advice, the worse it's wasted". Not that I haven't been wasted myself a
time or two.
> In other words, I went ahead and implemented it. Actually, it wasn't too
> bad, it only took about an hour of reading the ast.c code and the
> Grammar file (neither of which I had ever looked at before) to get the
> general sense of what's going on.
>
> So the general notion is similar to the various proposals on the Wiki -
> an inline keyword which serves the function of lambda. I chose the
> keyword "given" because it reminds me of math textbooks, e.g. "given x,
> solve for y". And I like the idea of syntactical structures that make
> sense when you read them aloud.
>
> Here's an interactive console session showing it in action.
>
> The first example shows a simple closure that returns the square of a
> number.
>
> >>> a = (x*x given x)
> >>> a(9)
> 81
>
> You can also put parens around the argument list if you like:
>
> >>> a = (x*x given (x))
> >>> a(9)
> 81
>
> Same thing with two arguments, and with the optional parens:
>
> >>> a = (x*y given x,y)
> >>> a(9, 10)
> 90
> >>> a = (x*y given (x,y))
> >>> a(9, 10)
> 90
>
> Yup, keyword arguments work too:
>
> >>> a = (x*y given (x=3,y=4))
> >>> a(9, 10)
> 90
> >>> a(9)
> 36
> >>> a()
> 12
>
> Use an empty paren-list to indicate that you want to define a closure
> with no arguments:
>
> >>> a = (True given ())
> >>> a()
> True
>
> Note that there are some cases where you have to use the parens around
> the arguments to avoid a syntactical ambiguity:
>
> >>> map( str(x) given x, (1, 2, 3, 4) )
> File "", line 1
> map( str(x) given x, (1, 2, 3, 4) )
> ^
> SyntaxError: invalid syntax
>
> As you can see, adding the parens makes this work:
>
> >>> map( str(x) given (x), (1, 2, 3, 4) )
> ['1', '2', '3', '4']
>
> More fun with "map":
>
> >>> map( str(x)*3 given (x), (1, 2, 3, 4) )
> ['111', '222', '333', '444']
>
> Here's an example that uses the **args syntax:
>
> >>> a = (("%s=%s" % pair for pair in kwargs.items()) given **kwargs)
> >>> list( a(color="red") )
> ['color=red']
> >>> list( a(color="red", sky="blue") )
> ['color=red', 'sky=blue']
>
> I have to say, the more I use it, the more I like it, but I'm sure that
> this is just a personal taste issue. It looks a lot more natural to me
> than lambda.
>
> I should also mention that I resisted the temptation to make the 'given'
> keyword an optional generator suffix as in "(a for a in l given l). As I
> started working with the code, I started to realize that generators and
> closures, although they have some aspects in common, are very different
> beasts and should not be conflated lightly. (Plus the implementation
> would have been messy. I took that as a clue :))
>
> Anyway, if anyone wants to play around with the patch, it is rather
> small - a couple of lines in Grammar, and a small new function in ast.c,
> plus a few mods to other functions to get them to call it. The context
> diff is less than two printed pages. I can post it somewhere if people
> are interested.
>
> Anyway, I am not going to lobby for a language change or write a PEP
> (unless someone asks me to.) I just wanted to throw this out there and
> see what people think of it. I definately don't want to start a flame
> war, although I suspect I already have :/
>
> Now I can stop thinking about this and go back to my TurboGears-based
> Thesaurus editor :)
>
Whether or not Guido can steel himself to engage in yet another round of
this seemingly interminable discussion, at least this proposal has the
merit of being concrete and not hypothetical.
It appears to hang together, but I'm not sure I see how it overcomes
objections to lambda by replacing it with another keyword.
regards
Steve
--
Steve Holden +44 150 684 7255 +1 800 494 3119
Holden Web LLC www.holdenweb.com
PyCon TX 2006 www.python.org/pycon/
___
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] str object going in Py3K
On 2/16/06, M.-A. Lemburg <[EMAIL PROTECTED]> wrote: > What will be the explicit way to open a file in bytes mode > and in text mode (I for one would like to move away from > open() completely as well) ? > > Will we have a single file type with two different modes > or two different types ? I'm currently thinking of an I/O stack somewhat like Java's. At the bottom there's a class that lets you do raw unbuffered reads and writes (and seek/tell) on binary files using bytes arrays. We can layer onto this buffering, text encoding/decoding, and more. (Windows CRLF<->LF conversion is also an encoding of sorts). Years ago I wrote a prototype; checkout sandbox/sio/. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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] bytes type discussion
On Thu, Feb 16, 2006 at 06:13:53PM +0100, Fredrik Lundh wrote: > Barry Warsaw wrote: > > > We know at least there will never be a 2.10, so I think we still have > > time. > > because there's no way to count to 10 if you only have one digit? > > we used to think that back when the gas price was just below 10 SEK/L, > but they found a way... > Of course they found a way. The alternative was cutting taxes. whish-I-was-winking, -Jack ___ 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
