[Python-Dev] Fixed URL to 2.6 documentation
Greetings, I'm writing a module for current Python 2.6 and I would like to reference documentation for Python 2.6, because I am not sure if behavior won't be changed in further series. So far I can link only to: http://docs.python.org/ (stable, 2.6) http://docs.python.org/dev/ (2.7) http://docs.python.org/dev/py3k/ When stable changes to 2.7 my reference will point to the different version than I was meant when writing comment. It is possible to link to docs for minor 2.6.4 http://www.python.org/doc/2.6.4/ but I would like to link to latest version of docs in 2.6 branch that may not yet found way into official minor release. -- anatoly t. ___ 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] The fate of the -U option
On Feb 03, 2010, at 09:55 AM, Guido van Rossum wrote:
>On Wed, Feb 3, 2010 at 9:09 AM, Barry Warsaw wrote:
>> -snip snip-
>> from __future__ import unicode_literals
>>
>> def func(foo, bar):
>> print foo, bar
>>
>> kw = {'foo': 7, 'bar': 9}
>> func(**kw)
>> -snip snip-
>>
>> That will raise a TypeError in 2.6 but works in 2.7. Is it appropriate and
>> feasible to back port that to Python 2.6? I remember talking about this a
>> while back but I don't remember what we decided and I can't find a bug on the
>> issue.
>
>I don't know about feasible but I think it's (borderline) appropriate.
>There are various other paths that lead to this error and it feels to
>me it's just a long-standing bug that we never took care of until 2.7.
>However, I don't think it needs to support non-ASCII characters in the
>keywords (even though 2.7 does seem to support those).
The back port from trunk of r68805 to fix this was really pretty trivial.
http://bugs.python.org/issue4978
http://bugs.python.org/file16124/py26-backport.patch
Assigned to Benjamin for review.
-Barry
signature.asc
Description: PGP signature
___
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] __file__
Brett Cannon wrote: > But what does "expected location" mean? If I am importing foo.bar > where foo.__path__ has multiple path entries, which one is supposed to > be used to set the hypothetical location of source for __file__? I > guess going with the first one would be somewhat reasonable, but it's > definitely a guess. No, it wouldn't be a guess, it would be based on where the compiled bytecode was actually found (wherever in foo.__path__ that may have been). So __file__ would be the same regardless of whether or not the source code was actually physically present or not. __compiled__ would be set only if the code being executed was read from that file rather than from __file__. Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia --- ___ 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] Forking and Multithreading - enemy brothers
Matt Knox a écrit : Jesse Noller gmail.com> writes: We already have an implementation that spawns a subprocess and then pushes the required state to the child. The fundamental need for things to be pickleable *all the time* kinda makes it annoying to work with. just a lurker here... but this topic hits home with me so thought I'd chime in. I'm a windows user and I would *love* to use multiprocessing a lot more because *in theory* it solves a lot of the problems I deal with very nicely (lot sof financial data number crunching). However, the pickling requirement makes it very very difficult to actually get any reasonably complex code to work properly with it. A lot of the time the functions I want to call in the spawned processes are actually fairly self contained and don't need most of the environment of the parent process shoved into it, so it's annoying that it fails because some data I don't even need in the child process can't be pickled. What about having an option to skip all the parent environment data pickling and require the user to manually invoke any imports that are needed in the target functions as the first step inside their target function? for example... def target_function(object_from_module_xyz): import xyz return object_from_module_xyz.do_something() and if I forgot to import all the stuff necessary for the arguments being passed into my function to work, then it's my own problem. Although maybe there is some obvious problem with this that I am not seeing. Anyway, just food for thought. - Matt Hello I don't really get it there... it seems to me that multiprocessing only requires picklability for the objects it needs to transfer, i.e those given as arguments to the called function, and thsoe put into multiprocessing queues/pipes. Global program data needn't be picklable - on windows it gets wholly recreated by the child process, from python bytecode. So if you're having pickle errors, it must be because the "object_from_module_xyz" itself is *not* picklable, maybe because it contains references to unpicklable objets. In such case, properly implementing pickle magic methods inside the object should do it, shouldn't it ? Regards, Pascal ___ 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 2.6.5
On Feb 03, 2010, at 11:50 PM, Ronald Oussoren wrote: >> Barry's answer was "yes" back in October. > >I will backport the patch if Barry says it's fine. Feel free to ping me if >that doesn't happen before the end of next week. I still think this should go in 2.6.5. The patch does not apply to the current 2.6 branch because of changes in setup.py. If the patch is ported, reviewed and works with no regressions (when libreadline is both installed on OS X 10.5 and 10.6 or not), then I'm okay with this going in. I've made it a release blocker for 2.6.5 for now. -Barry signature.asc Description: PGP signature ___ 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 -U
On Feb 03, 2010, at 08:52 PM, Martin v. Löwis wrote: >>> As an aside, I think this should be documented *somewhere* other than >>> just in import.c! I'd totally forgotten about it until I read the >>> source and almost missed it. Either it should be documented or it >>> should be ripped out. >> >> The -U option is already gone in 3.x. > >Precisely my view. I took the "or document it" approach. http://bugs.python.org/file16127/7847.patch http://bugs.python.org/issue7847 -Barry signature.asc Description: PGP signature ___ 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] Forking and Multithreading - enemy brothers
Pascal Chambon writes: > I don't really get it there... it seems to me that multiprocessing only > requires picklability for the objects it needs to transfer, i.e those > given as arguments to the called function, and thsoe put into > multiprocessing queues/pipes. Global program data needn't be picklable - > on windows it gets wholly recreated by the child process, from python > bytecode. > > So if you're having pickle errors, it must be because the > "object_from_module_xyz" itself is *not* picklable, maybe because it > contains references to unpicklable objets. In such case, properly > implementing pickle magic methods inside the object should do it, > shouldn't it ? I'm also a long time lurker (and in financial software, coincidentally). Pascal is correct here. We use a number of C++ libraries wrapped via Boost.Python to do various calculations. The typical function calls return wrapped C++ types. Boost.Python types are not, unfortunately, pickleable. For a number of technical reasons, and also unfortunately, we often have to load these libraries in their own process, but we want to hide this from our users. We accomplish this by pickling the instance data, but importing the types fresh when we unpickle, all implemented in the magic pickle methods. We would lose any information that was dynamically added to the type in the remote process, but we simply don't do that. We very often have many unpickleable objects imported somewhere when we spin off our processes using the multiprocess library, and this does not cause any problems. Jesse Noller gmail.com> writes: > We already have an implementation that spawns a > subprocess and then pushes the required state to the child. The > fundamental need for things to be pickleable *all the time* kinda > makes it annoying to work with. This requirement puts a fairly large additional strain on working with unwieldy, wrapped C++ libraries in a multiprocessing environment. I'm not very knowledgeable on the internals of the system, but would it be possible to have some kind of fallback system whereby if an object fails to pickle we instead send information about how to import it? This has all kinds of limitations - it only works for importable things (i.e. not instances), it can potentially lose information dynamically added to the object, etc., but I thought I would throw the idea out there so someone knowledgeable can decide if it has any merit. Ben ___ 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] Forking and Multithreading - enemy brothers
On 04:58 pm, [email protected] wrote: Jesse Noller gmail.com> writes: We already have an implementation that spawns a subprocess and then pushes the required state to the child. The fundamental need for things to be pickleable *all the time* kinda makes it annoying to work with. This requirement puts a fairly large additional strain on working with unwieldy, wrapped C++ libraries in a multiprocessing environment. I'm not very knowledgeable on the internals of the system, but would it be possible to have some kind of fallback system whereby if an object fails to pickle we instead send information about how to import it? This has all kinds of limitations - it only works for importable things (i.e. not instances), it can potentially lose information dynamically added to the object, etc., but I thought I would throw the idea out there so someone knowledgeable can decide if it has any merit. It's already possible to define pickling for arbitrary objects. You should be able to do this for the kinds of importable objects you're talking about, and perhaps even for some of the actual instances (though that depends on how introspectable they are from Python, and whether the results of this introspection can be used to re-instantiate the object somewhere else). Take a look at the copy_reg module. 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] PEP 345 and PEP 386
All, I've reviewed PEP 345 and PEP 386 and am satisfied that after some small improvements they will be accepted. Most of the discussion has already taken place. I have one comment on PEP 345: Why is author-email mandatory? I'm sure there are plenty of cases where either the author doesn't want their email address published, or their last know email address is no longer valid. (Tarek responded off-line that it isn't all that mandatory; I propose to say so in the PEP.) I am also looking at PEP 376 but I expect that Tarek will start another round of discussion on it. Hopefully all three PEPs will be accepted in time for inclusion in Python 2.7. -- --Guido van Rossum (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] PEP 3147: PYC Repository Directories
On Wed, Feb 3, 2010 at 13:33, "Martin v. Löwis" wrote: > Guido van Rossum wrote: > > On Wed, Feb 3, 2010 at 12:47 PM, Nick Coghlan > wrote: > >> On the issue of __file__, I'd suggesting not being too hasty in > >> deprecating that in favour of __source__. While I can see a lot of value > >> in having it point to the source file more often with a different > >> attribute that points to the cached file, I don't see a lot of gain to > >> compensate for the pain of changing the name of __file__ itself. > > > > Can you clarify? In Python 3, __file__ always points to the source. > > Clearly that is the way of the future. For 99.99% of uses of __file__, > > if it suddenly never pointed to a .pyc file any more (even if one > > existed) that would be just fine. So what's this talk of switching to > > __source__? > > I originally proposed it, not knowing that Python 3 already changed the > meaning of __file__ for byte code files. > > What I really wanted to suggest is that it should be possible to tell > what gets really executed, plus what source file had been considered. > > So if __file__ is always the source file, a second attribute should tell > whether a byte code file got read (so that you can delete that in case > you doubt it's current, for example). > > What should be done for loaders? Right now we have get_filename() which is what __file__ is to be set to. For importlib there is source_path and bytecode_path, but both of those are specified to return None in the cases of source or bytecode are not available, respectively. The bare minimum, I think, is we need loaders to have mehod(s) that return the path to the source -- whether it exists or not, to set __file__ to -- and the path to bytecode if it exists -- to set __compiled__ or whatever attribute we come up with. That suggests to me either two new methods or one that returns a two-item tuple. We could possibly keep get_filename() and say that people need to compare its output to what source_path()-equivalent method returns, but that seems bad if the source location needs to be based on the bytecode location. My thinking is we deprecate get_filename() and introduce some new method that returns a two-item tuple (get_paths?). First item is where the source should be, and the second is where the bytecode is if it exists (else it's None). Putting both calculations into a single method seems better than a source_path()/bytecode_path() as the latter would quite possibly need source_path() to call bytecode_path() on its own to calculate where the source should be if it doesn't exist on top of the direct call to get_bytecode() for setting __compiled__ itself. -Brett > 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/brett%40python.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] Fixed URL to 2.6 documentation
On Thu, Feb 4, 2010 at 00:57, anatoly techtonik wrote: > Greetings, > > I'm writing a module for current Python 2.6 and I would like to > reference documentation for Python 2.6, because I am not sure if > behavior won't be changed in further series. So far I can link only > to: > > http://docs.python.org/ (stable, 2.6) > http://docs.python.org/dev/ (2.7) > http://docs.python.org/dev/py3k/ > > When stable changes to 2.7 my reference will point to the different > version than I was meant when writing comment. It is possible to link > to docs for minor 2.6.4 http://www.python.org/doc/2.6.4/ but I would > like to link to latest version of docs in 2.6 branch that may not yet > found way into official minor release. > > As you said, something in 2.6 could change, so linking to a 2.6.x doc link instead of a specific version could be misleading in your docs if a change did occur that you were not aware about. But since micro releases rarely have anything change in them you should be able to link to practically any release and feel comfortable in knowing that things should stay the same through all of 2.6.x. -Brett ___ 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 3147: PYC Repository Directories
On approximately 1/30/2010 4:00 PM, came the following characters from the keyboard of Barry Warsaw: When the Python executable is given a `-R` flag, or the environment variable `$PYTHONPYR` is set, then Python will create a `foo.pyr` directory and write a `pyc` file to that directory with the hexlified magic number as the base name. After the discussion so far, my opinion is that if the source directory contains an appropriate python repositiory directory [1], and the version of Python implements PEP 3147, that there should be no need for -R or $PYTHONPYR to exist, but that such versions of Python would simply, and always look in the python repository directory for binaries. I've reached this conclusion for several reasons/benefits: 1) it makes the rules simpler for people finding the binaries 2) there is no "double lookup" to find a binary at run time 3) if the PEP changes to implement alternatives B or C in [1], then I hear a large consensus of people that like that behavior, to clean up the annoying clutter of .pyc files mixed with source. 4) There is no need to add or document the command line option or environment variable. [1] Alternative A... source-file-root.pyr, as in the PEP, Alt. B... source-file-dir/__pyr__ all versions/files in same lookaside directory, Alt. C... source-file-dir/__pyr_version__, each Python version with different bytecode would have some sort of version string or magic number that identifies it, and would look only in that directory for its .pyc/.pyo files. I prefer C for 4 reasons: 1) easier to blow away one version; 2) easier to see what that version has compiled; 3) most people use only one or two versions, so directory proliferation is limited; 4) even when there are 30 versions of Python, the subdirectories would contain the same order-of-magnitude count of files as the source directory for performance issues, if the file system has a knee in the performance curve as some do. -- Glenn -- http://nevcal.com/ === A protocol is complete when there is nothing left to remove. -- Stuart Cheshire, Apple Computer, regarding Zero Configuration Networking ___ Python-Dev mailing list [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 2.6.5
On Feb 4, 2010, at 4:59 AM, Barry Warsaw wrote: > I still think this should go in 2.6.5. The patch does not apply to the > current 2.6 branch because of changes in setup.py. If the patch is ported, > reviewed and works with no regressions (when libreadline is both installed on > OS X 10.5 and 10.6 or not), then I'm okay with this going in. > > I've made it a release blocker for 2.6.5 for now. I attached the patch that applies cleanly to 2.6 branch to issue6877. The details are in the comments (msg98858 and msg98859). Zvezdan ___ 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 3147: PYC Repository Directories
Brett Cannon wrote: > My thinking is we deprecate get_filename() and introduce some new method > that returns a two-item tuple (get_paths?). First item is where the > source should be, and the second is where the bytecode is if it exists > (else it's None). Putting both calculations into a single method seems > better than a source_path()/bytecode_path() as the latter would quite > possibly need source_path() to call bytecode_path() on its own to > calculate where the source should be if it doesn't exist on top of the > direct call to get_bytecode() for setting __compiled__ itself. If we add a new method like get_filenames(), I would suggest going with Antoine's suggestion of a tuple for __compiled__ (allowing loaders to indicate that they actually constructed the runtime bytecode from multiple cached files on-disk). The runpy logic would then be something like: try: method = loader.get_filenames except AttributeError: __compiled__ = () try: method = loader.get_filename except: __file__ = None else: __file__ = method() else: __file__, *__compiled__ = method() For the import machinery itself, setting __compiled__ would be the responsibility of the loaders due to the way load_module is specified. I still sometimes wonder if we would be better off splitting that method into separate "prepare_module" and "exec_module" methods to allow the interpreter a chance to fiddle with the module globals before the module code gets executed. Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia --- ___ 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 3147: PYC Repository Directories
Glenn Linderman wrote: > Alt. C... source-file-dir/__pyr_version__, each Python version with > different bytecode would have some sort of version string or magic > number that identifies it, and would look only in that directory for its > .pyc/.pyo files. I prefer C for 4 reasons: 1) easier to blow away one > version; 2) easier to see what that version has compiled; 3) most people > use only one or two versions, so directory proliferation is limited; 4) > even when there are 30 versions of Python, the subdirectories would > contain the same order-of-magnitude count of files as the source > directory for performance issues, if the file system has a knee in the > performance curve as some do. I don't think this suggestion had come up before, but I like it. It also reduces the amount of filename adjustment needed in the individual cache directories. Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia --- ___ 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 3147: PYC Repository Directories
On Thu, Feb 4, 2010 at 13:51, Nick Coghlan wrote: > Brett Cannon wrote: > > My thinking is we deprecate get_filename() and introduce some new method > > that returns a two-item tuple (get_paths?). First item is where the > > source should be, and the second is where the bytecode is if it exists > > (else it's None). Putting both calculations into a single method seems > > better than a source_path()/bytecode_path() as the latter would quite > > possibly need source_path() to call bytecode_path() on its own to > > calculate where the source should be if it doesn't exist on top of the > > direct call to get_bytecode() for setting __compiled__ itself. > > If we add a new method like get_filenames(), I would suggest going with > Antoine's suggestion of a tuple for __compiled__ (allowing loaders to > indicate that they actually constructed the runtime bytecode from > multiple cached files on-disk). > > Does code exist out there where people are constructing bytecode from multiple files for a single module? > The runpy logic would then be something like: > > try: >method = loader.get_filenames > except AttributeError: >__compiled__ = () >try: > method = loader.get_filename >except: > __file__ = None >else: > __file__ = method() > else: >__file__, *__compiled__ = method() > > Should it really be a flat sequence that get_filenames returns? That first value has a very special meaning compared to the rest which suggests to me keeping the returned sequence to two items, just with the second item being a sequence itself. > > For the import machinery itself, setting __compiled__ would be the > responsibility of the loaders due to the way load_module is specified. Yep. > I > still sometimes wonder if we would be better off splitting that method > into separate "prepare_module" and "exec_module" methods to allow the > interpreter a chance to fiddle with the module globals before the module > code gets executed. > There's a reason why importlib has its ABCs abstracted the way it does; there's a bunch of stuff that can be automated and is common to all loaders that load_module has to cover. We could consider refactoring the API, but I don't know if it is worth the hassle since importlib has decorators that take care of low-level commonality and has ABCs for higher-level stuff. But yes, given a do-over, I would abstract loaders to a finer grain to let import handle more of the details. -Brett > > Cheers, > Nick. > > -- > Nick Coghlan | [email protected] | Brisbane, Australia > --- > ___ 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 3147: PYC Repository Directories
Glenn Linderman wrote: On approximately 1/30/2010 4:00 PM, came the following characters from the keyboard of Barry Warsaw: When the Python executable is given a `-R` flag, or the environment variable `$PYTHONPYR` is set, then Python will create a `foo.pyr` directory and write a `pyc` file to that directory with the hexlified magic number as the base name. After the discussion so far, my opinion is that if the source directory contains an appropriate python repositiory directory [1], and the version of Python implements PEP 3147, that there should be no need for -R or $PYTHONPYR to exist, but that such versions of Python would simply, and always look in the python repository directory for binaries. How would the python repository directory ever get created? ___ 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 345 and PEP 386
On Thu, Feb 4, 2010 at 8:20 PM, Guido van Rossum wrote: [..] > I have one comment on PEP 345: Why is author-email mandatory? I'm sure > there are plenty of cases where either the author doesn't want their > email address published, or their last know email address is no longer > valid. (Tarek responded off-line that it isn't all that mandatory; I > propose to say so in the PEP.) Yes, I propose to remove the mandatory flag from that field. > I am also looking at PEP 376 but I expect that Tarek will start > another round of discussion on it. Hopefully all three PEPs will be > accepted in time for inclusion in Python 2.7. We will work on 376 in the two coming weeks in distutils-SIG and try to come up with something ready for Pycon, if feasible. Thanks for the reviews ! Tarek -- Tarek Ziadé | http://ziade.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] PEP 3147: PYC Repository Directories
On approximately 2/4/2010 2:28 PM, came the following characters from the keyboard of Eric Smith: Glenn Linderman wrote: On approximately 1/30/2010 4:00 PM, came the following characters from the keyboard of Barry Warsaw: When the Python executable is given a `-R` flag, or the environment variable `$PYTHONPYR` is set, then Python will create a `foo.pyr` directory and write a `pyc` file to that directory with the hexlified magic number as the base name. After the discussion so far, my opinion is that if the source directory contains an appropriate python repositiory directory [1], and the version of Python implements PEP 3147, that there should be no need for -R or $PYTHONPYR to exist, but that such versions of Python would simply, and always look in the python repository directory for binaries. How would the python repository directory ever get created? When a PEP 3147 (if modified by my suggestion) version of Python runs, and the directory doesn't exist, and it wants to create a .pyc, it would create the directory, and put the .pyc there. Sort of just like how it creates .pyc files, now, but an extra step of creating the repository directory if it doesn't exist. After the first run, it would exist. It is described in the PEP, and I quoted that section... "Python will create a 'foo.pyr' directory"... I'm just suggesting different semantics for how many directories, and what is contained in them. -- Glenn “Everyone is entitled to their own opinion, but not their own facts. In turn, everyone is entitled to their own opinions of the facts, but not their own facts based on their opinions.” -- Guy Rocha, retiring NV state archivist ___ 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] Fixed URL to 2.6 documentation
Am 04.02.2010 08:57, schrieb anatoly techtonik: > Greetings, > > I'm writing a module for current Python 2.6 and I would like to > reference documentation for Python 2.6, because I am not sure if > behavior won't be changed in further series. So far I can link only > to: > > http://docs.python.org/ (stable, 2.6) > http://docs.python.org/dev/ (2.7) > http://docs.python.org/dev/py3k/ > > When stable changes to 2.7 my reference will point to the different > version than I was meant when writing comment. It is possible to link > to docs for minor 2.6.4 http://www.python.org/doc/2.6.4/ but I would > like to link to latest version of docs in 2.6 branch that may not yet > found way into official minor release. You can always use http://docs.python.org/2.6/ as the base for 2.6 docs. It currently redirects to /, but it will redirect to some other place with up-to-date 2.6 docs as soon as 2.7 is released. Georg ___ 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
