[Python-Dev] eggs now mandatory for pypi?
it's revews like this that makes me wonder if releasing open source is a good idea: no egg - worst seen ever, remove it from pypi or provide an egg (jensens, 2009-10-05, 0 points) /F ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] eggs now mandatory for pypi?
Oh, it was just yet another Zope developer behaving like an ass. Why am I not surprised? /F On Mon, Oct 5, 2009 at 10:43 AM, Fredrik Lundh fred...@pythonware.com wrote: it's reviews like this that makes me wonder if releasing open source is a good idea: no egg - worst seen ever, remove it from pypi or provide an egg (jensens, 2009-10-05, 0 points) /F ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] eggs now mandatory for pypi?
He's not the first one from the Zope community (whatever that is) that's behaved this way on this specific topic. The problem here is that a certain (marginal) user community decides to standardize on a certain distribution model, and then goes off attacking people who've released stuff *before* they did that. That *is* a community problem. (Luckily, there are people helping out, and the nice people driven-development rule overrides that other rule I mentioned, so things will get tweaked sooner or later.) /F On Mon, Oct 5, 2009 at 1:02 PM, Nick Coghlan ncogh...@gmail.com wrote: Fredrik Lundh wrote: Oh, it was just yet another Zope developer behaving like an ass. Why am I not surprised? Tarring an entire community for the actions of one twit is more than a little unfair. It's fine that you don't like eggs and it's fine that you don't want to provide them. There's a reason egg-based packaging tools make it fairly easy to create an egg from a normal sdist package. As for people being twits... it's the internet. There isn't a lot to be done other than to ignore them. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia --- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PIL vs. Imaging (was Re: eggs now mandatory for pypi?)
On Mon, Oct 5, 2009 at 8:48 PM, P.J. Eby p...@telecommunity.com wrote: names for the same thing. (I'm guessing that PIL was registered on PyPI manually, before the setup.py register command existed. Heck, it was probably being distributed before the distutils even existed, and indeed before there were such things as packages in Python.) $ more PIL/Image.py ... # partial release history: # 1995-09-09 fl Created # 1996-03-11 fl PIL release 0.0 # 1996-04-30 fl PIL release 0.1b1 ... Looks like the quickest fix is to distribute two source packages, one built the traditional way to eliminate breakage for people using the current tarball layout, and one built with sdist. /F ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] xmlrpc improvements
On Sat, Jun 20, 2009 at 6:57 PM, Martin v. Löwismar...@v.loewis.de wrote: Fredrik Lundh wrote: I think you really need to get Fredrik Lundh to comment on it. If he can't predict when he'll be able to review the changes, maybe he can accept releasing control of xmlrpclib. Pointer to the patch? http://bugs.python.org/issue6267 The xmlrpclib.py changes looks ok. I'll leave it to other reviewers to check the rest. /F ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] xmlrpc improvements
On Sat, Jun 20, 2009 at 6:57 PM, Martin v. Löwismar...@v.loewis.de wrote: While I have your attention, please also review http://bugs.python.org/issue6233 I'm pretty sure that fix is the wrong fix - afaik, _encode is used to encode tag/attribute names, and charrefs don't work in that context. /F ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] xmlrpc improvements
2009/6/20 Martin v. Löwis mar...@v.loewis.de: I‘d really like to get this stuff in. The performance gains allowing http1.1 and gzip for xmlrpc are quite significant. I think you really need to get Fredrik Lundh to comment on it. If he can't predict when he'll be able to review the changes, maybe he can accept releasing control of xmlrpclib. Pointer to the patch? /F ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] c99 comments in the 2.6 code base?
http://drj11.wordpress.com/2008/10/02/python-and-bragging-about-c89/ mentions that Objects/frameobject.c contains a C99-style comment, which means that Python 2.6 won't build on AIX. shouldn't we use a suitable gcc option for the buildbots to prevent that from happening? /F ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PyCon 2009 Call for Proposals
Brett Cannon wrote: You sit in front of a bunch of people answering questions asked by the audience. You know, a panel. =) It's just a QA session so that PyCon attendees can ask python-dev a bunch of random questions. Demystifies some things and puts faces to python-dev. and using moderator.appspot.com to gather questions from off-site attendees, perhaps? /F ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] how about updating PEP 290?
the Code Migration and Modernization PEP hasn't been updated for 2.5 and 2.6. http://www.python.org/dev/peps/pep-0290/ surely there's something new in 2.5 and 2.6 that might be worth mentioning? /F ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] ',' precedence in documentation
C. Titus Brown wrote:
over on the pygr list, we were recently discussing a mildly confusing
edit I made:
assert 'seq1' in self.db, self.db.keys()
This was interpreted by someone as being
assert 'seq1' in (self.db, self.db.keys())
which is very different from the actual meaning,
assert ('seq1' in self.db), self.db.keys()
where 'self.db.keys()' serves as the message to be printed out when the
assertion fails. Apart from questions of why I was apparently out to
confuse people with this edit, the question of ',' precedence came up.
Looking at
http://docs.python.org/ref/summary.html
there's no mention of ',' binding and tuple creation vs the other
operators.
A bare , is part of the expression list syntax; it's not an operator:
http://docs.python.org/ref/exprlists.html
You have to look at the statement descriptions to find out whether a
statement wants an expression or an expression list (e.g. return takes
an expression list, while assert takes two expressions, not two
expression lists).
/F
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] HTTPS read-only SVN access is denied?
Olemis Lang wrote: Fetching external item into 'docutils' svn: Can't connect to host 'svn.berlios.de': A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond. Please I need some help so as to finally check out all the PEPs at once. I suspect you already have all the PEP:s; the checkout command gets stuck when trying to fetch some additional software from an external server. try adding the --ignore-externals option to the checkout command, and see if this gets you any further. then check if you can reach http://svn.berlios.de via your browser, or if some firewall rule gets in the way. /F ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Not releasing rc1 tonight
Barry Warsaw wrote: I'm not going to release rc1 tonight. There are too many open release blockers that I don't want to defer, and I'd like the buildbots to churn through the bsddb removal on all platforms. I'd like to try again on Friday and stick to rc2 on the 17th. any news on this front? (I have a few minor ET fixes, and possibly a Unicode 5.1 patch, but have had absolutely no time to spend on that. is the window still open?) /F ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Not releasing rc1 tonight
Barry Warsaw wrote: (I have a few minor ET fixes, and possibly a Unicode 5.1 patch, but have had absolutely no time to spend on that. is the window still open?) There are 8 open release blockers, a few of which have patches that need review. So I think we are still not ready to release rc1. So what's the new ETA? Should I set aside some time to work on the patches, say, tomorrow, or is it too late? /F ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Can/should built-in functions get __get__?
Terry Reedy wrote: In particular, built-in functions, in spite of of being labeled 'builtin_function_or_method', are not usable as methods because they lack the __get__ method needed to bind function to instance. They're not usable as Python-level instance methods, but they're definitely usable as methods, since they're used to implement methods for built-in types. I'm probably missing something, but I don't think there's a convenient method to get the internal function from a built-in type. However, you can find traces of them here and there: .upper.hello Traceback (most recent call last): File stdin, line 1, in module AttributeError: 'builtin_function_or_method' object has no attribute 'hello' .upper.__call__ method-wrapper '__call__' of builtin_function_or_method object at 0x00C06260 etc. /F ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Further PEP 8 compliance issues in threading and multiprocessing
Benjamin Peterson wrote: Does anybody ever complain about not being able to use isinstance on twisted.application.Application? (At least it's documented as a function there.) the threading non-classes are documented to be factory functions on the module page. /F ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Further PEP 8 compliance issues in threading and multiprocessing
Antoine Pitrou wrote: event_class = Event().__class__ ? Not pretty I know :-) somewhat prettier, assuming 2.3 or newer: import threading e = threading.Event() type(e) class 'threading._Event' isinstance(e, type(threading.Event())) True (but pretty OT) /F ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] the explicit self
Kilian Klimek wrote: Saying your method must accept an extra parameter (which most people call 'self') that carries all object attributes is hardly any more explicit then saying there is a special variable (which is always named 'this') that carries all object attributes. in this context, implicit and explicit refers to the code, not the documentation. /F ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] subprocess insufficiently platform-independent?
Guido van Rossum wrote: I can't reproduce this as described. Which Windows version? This sounds like one of those things that could well vary by Windows version; if it works for you in Vista it may well be broken in XP. It could also vary by other setup parameters besides PATHEXT. It works the same way on XP, at least: import subprocess cmd = ['svn', 'ls', '.'] subprocess.call(cmd, shell=False) svn: '.' is not a working copy 1 According to the MS docs, CreateProcess works the same way on at least 2K, XP and Vista. The documentation is a bit vague (as usual), but it contains an example that implies that CreateProcess always adds .exe if not already there, and that you need to use the command interpreter (that is, shell=True) if you want to run something that's not a Windows executable module (e.g. a batch file). /F ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] subprocess insufficiently platform-independent?
Curt Hagenlocher wrote: I've found the documentation for CreateProcess (http://msdn.microsoft.com/en-us/library/ms682425.aspx) to be pretty reliable. And the mention of a .com in the docs suggests that the description has been around for a while... And I just described it as pretty vague ;-) Reading it again, I realize that I completely missed the part that says: If the file name does not contain an extension, .exe is appended. Therefore, if the file name extension is .com, this parameter must include the .com extension. If the file name ends in a period (.) with no extension, or if the file name contains a path, .exe is not appended. /F ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] confusing exec error message in 3.0
(using 3.0a4) exec(open(file.py)) Traceback (most recent call last): File stdin, line 1, in module TypeError: exec() arg 1 must be a string, file, or code object, not TextIOWrapper so what's file referring to here? (the above works under 2.5, of course) /F ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] confusing exec error message in 3.0
Fredrik Lundh wrote: (using 3.0a4) ahem. I could have sworn that I installed a beta, but I guess the Windows builds weren't fully synchronized when I did that. I still get the same error after updating to 3.0b2, though. (the download page still says This is an alpha release, btw.) /F ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Unicode 5.1.0
Barry Warsaw wrote: I agree. This seriously feels like new, potentially high risk code to be adding this late in the game. The BDFL can always override, but unless someone is really convincing that this is low risk high benefit, I'd vote no for 2.6/3.0. at least two Unicode experts have stated that they don't think the changes are that important. determining exactly what the changes to the *core* character database was the whole point of my offer to tinker with this. (I got distracted due to compiler issues and certain other things to be announced later, but I expect to have some results later this week). /F ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Unicode 5.1.0
Barry Warsaw wrote: You don't mean the experts claimed they weren't important, right? Unimportant changes definitely don't need to go in now wink. Well, at least Guido managed to figure out what I was trying to say ;-) /F ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] error: None when building extensions under 2.6
Amaury Forgeot d'Arc wrote: when I'm trying to build extensions under Python 2.6 on Windows XP, the build process terminates with single line that says: error: None which is about as useless as an error message can be. Googling for this brings up a few hits which all seem to involve setuptools (and none of the hits contain any answers), but I'm using straightforward distutils stuff that has worked without a glitch since 1.5.2. Has anyone else seen this for 2.6? I tried to rebuild some extensions, and it either succeeds, or fails with a meaningful (for an expert) error message. Which extensions did you try? is there some output before the error? pick any: http://effbot.org/downloads/ ;-) I'm beginning to suspect that I have a botched VS install on this machine, though. I'll investigate. /F ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] error: None when building extensions under 2.6
Thomas Heller wrote: I'm beginning to suspect that I have a botched VS install on this machine, though. I'll investigate. Do you get a traceback when you set the DISTUTILS_DEBUG environment variable? Indeed I do: ... File c:\python26\lib\distutils\msvc9compiler.py, line 436, in compile self.initialize() File c:\python26\lib\distutils\msvc9compiler.py, line 347, in initialize vc_env = query_vcvarsall(VERSION, plat_spec) File c:\python26\lib\distutils\msvc9compiler.py, line 239, in query_vcvarsall raise IOError(Unable to find vcvarsall.bat) Oops. Guess that's what you get for having too many Windows development boxes ;-) (a nicer error message in non-debug mode would be a good thing, I think.) /F PS. Can any resident Microsoft compiler expert perhaps summarize the differences between the Express Edition and the real editions wrt. generated code? Are there any differences at all? ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] String concatenation
Tres Seaver wrote: - -1. The feature exists to allow adherence to PEP-8, Limit all lines to a maximum of 79 characters., without requiring runtime concatenation costs. I use it frequently when assembling and testing message strings, for instance. removing it is a bad idea for the reasons already given, but requiring parentheses could help. that is, the following would result in a warning or an error: L = [first, second third] but the following wouldn't: L = [first, (second third)] T = (This is a line of text.\n This is another line of text.\n) etc. /F ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] String concatenation
Isaac Morland wrote: This would avoid accidentally leaving out commas in list construction, but tuple construction would still have the same problem. Tuple construction already has a no comma, no tuple problem. That problem remains, but as soon as you add a comma, you'll get the same protection as you get for lists. And it's still a change in the language which would probably affect lots of existing code. Having read and written tons of existing code, I'm not so sure about that. A tool that wraps backslash-escaped blocks in parentheses would take care of most cases. What's left after that is probably ambiguous to a human reader anyway. F ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] error: None when building extensions under 2.6
when I'm trying to build extensions under Python 2.6 on Windows XP, the build process terminates with single line that says: error: None which is about as useless as an error message can be. Googling for this brings up a few hits which all seem to involve setuptools (and none of the hits contain any answers), but I'm using straightforward distutils stuff that has worked without a glitch since 1.5.2. Has anyone else seen this for 2.6? /F ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Unicode 5.1.0
On Fri, Aug 22, 2008 at 3:25 AM, Guido van Rossum [EMAIL PROTECTED] wrote: So while we could say: we provide access to the Unicode 5.1.0 database, we cannot say: we support Unicode 5.1.0, simply because we have not reviewed the all the necessary changes and implications. Mark's response to this was: I'd suspect that you'll be as conformant to U5.1.0 as you were to U4.1.0 ;-) is the suggestion to *replace* the 4.1.0 database with a 5.1.0 database, or to add yet another database in that module? (how's the 3.2/4.1 dual support implemented? do we have two distinct datasets, or are the differences encoded in some clever way? would it make sense to split the unicodedata module into three separate modules, one for each major Unicode version?) /F ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Unicode 5.1.0
On Fri, Aug 22, 2008 at 4:59 PM, Guido van Rossum [EMAIL PROTECTED] wrote:
(how's the 3.2/4.1 dual support implemented? do we have two distinct
datasets, or are the differences encoded in some clever way? would it
make sense to split the unicodedata module into three separate
modules, one for each major Unicode version?)
The current API looks fine to me: unicodedata is the latest version
whereas unicodedata.ucd_3_2_0 is the older version. The APIs are the
same; there's a tiny bit of code in the generated _db.h file that
expresses the differences:
static const change_record* get_change_3_2_0(Py_UCS4 n)
{
int index;
if (n = 0x11) index = 0;
else {
index = changes_3_2_0_index[n7];
index = changes_3_2_0_data[(index7)+(n 127)];
}
return change_records_3_2_0+index;
}
there's a bunch of data tables as well, but they don't seem to be very
large. looks like Martin did a thorough job here.
... digging digging digging ...
yes, the generator script produces difference tables between the main
version and a list of older versions. I'd say it's worth running the
script on the 5.1.0 tables, and if it doesn't choke, compare the
resulting table with the corresponding table for 4.1.0 (a simple loop
fetching the main properties for all code points). if the differences
look reasonably small, switch 5.1.0 and keep the others.
I can tinker a little with this over the weekend, unless Martin tells
me not to ;-)
/F
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Unicode 5.1.0
when did Python-Dev turn into a members only list, btw? --- Your mail to 'Python-Dev' with the subject Re: Unicode 5.1.0 Is being held until the list moderator can review it for approval. The reason it is being held: Post by non-member to a members-only list --- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] regexp in Python
Bartlomiej Wolowiec wrote: For some time I'm interested in regular expressions and Finite State Machine. Recently, I saw that Python uses Secret Labs' Regular Expression Engine, which very often works too slow. Its pesymistic time complexity is O(2^n), although other solutions, with time complexity O(n*m) ( O(n*m^2), m is the length of the regular expression and n is the length of the text, introduction to problem: http://swtch.com/~rsc/regexp/regexp1.html ) that article almost completely ignores all the subtle capturing and left- to-right semantics that a perl-style engine requires, though. trust me, this is a much larger can of worms than you might expect. but if you're ready to open it, feel free to hack away. major part of regular expressions the contrived example you used has nothing whatsoever to do with major part of regular expressions as seen in the wild, though. I'd be much more interested in optimizations that focuses on patterns you've found in real code. /F ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] deprecate commands.getstatus()
Guido van Rossum wrote: What about reimplementing commands.* using subprocess? Or providing a commands.*-compatible interface in the subprocess module? What does that buy us? multi-platform support? (commands is Unixoid only, right?) /F ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] splitext('.cshrc')
Martin v. Löwis wrote: I never considered it an extension. Ask 10 people around you to see what a leading dot on Unix in a file name means, and I would be suprised if more than one answered it separates the file name from the extension. Most of them likely include hidden file in their answer, and the rest (of those who know anything about it) will say dotfiles, not displayed by ls, and not included in globbing. 10 Unix programmers, perhaps. Windows users may disagree; after all, the Windows Explorer considers both foo.bar and .bar to be BAR files, and considers .py to be an unnamed Python file. /F ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Py_ssize_t
Guido van Rossum wrote: My suspicion is that building Python for an 64-bit address space is still a somewhat academic exercise. arbitrary 64-bit systems, perhaps. the first Python system I ever built was deployed on an LP64 system back in 1995. it's still running, and is still being maintained. /F ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Pydoc Improvements / Rewrite
Talin wrote: Rather than fixing on a standard markup, I would like to see support for a __markup__ module variable which specifies the specific markup language that is used in that module. Doc processors could inspect that variable and then load the appropriate markup translator. Ideally, a module should be able to specify what *documentation provider* to use. Not everyone wants to stuff everything into docstrings, and, especially if you're building larger components, automatic introspection simply doesn't work very well. fwiw, I have hacks for PythonDoc that monkey-patches inspect to provide virtual docstrings, but it would be nice to have an official API for this. It doesn't have to be much more complicated than: def __inspect__(path, format_hint=None): ... return format, data, subpaths where path is a dotted path to the target object, and format_hint is a preferred format. Why? Because its hard to get everyone to agree on which markup language is best for documentation. I personally think that reStructuredText is not a good choice, because I want to add markup that adds semantic information, whereas reStructuredText deals solely with presentation and visual appearance. And does a rather bad job at that too (the squint if you don't want to see the markup approach is fundamentally flawed), but that's another story for another forum. /F ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fwd: survey about the use of agile practices
Guido van Rossum wrote: Even apart from the website that Samuele found, the content sounded genuine. Just not something I feel like dealing with (too many surveys). from what I can tell, it was blasted to everyone with a sourceforge account, which indicates that they're don't really care what projects or persons they get information from. even if it's a genuine survey, it's crap science. /F ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] MSI being downloaded 10x morethan all other files?!
Kurt B. Kaiser wrote: Going mainstream :-)) indeed. from what I can tell on my local market, we've crossed the chasm [1], and are seeing wider range of pragmatists adding Python to the tool chain. The Rails buzz seems to be jumping to Python lately. fwiw, the people I see pick up Python haven't even heard of Ruby or Rails (not every- one is doing web 2.0 stuff, after all). /F 1) http://www.testing.com/writings/reviews/moore-chasm.html ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adding resume (206) support to urllib(2)
Martin v. Löwis wrote: I've just been putting together a podcasting doodad and have included resuming support in it. Is this something that's already in the pipeline or should I abstract it out to urllib and submit a patch? Not sure where you got the impression that 206 is resume; in my copy of the spec it's partial content, and you must have put a Range: header into the request to get that in the first place. If I had to use that, I'd implement it right on top of httplib, and wouldn't bother with urllib*: this is really specific to http, and adding it to urllib would break the abstraction. given that urllib2 already supports partial requests, I'm not sure I see the point of reimplementing this on top of httplib. an example: import urllib2 request = urllib2.Request(http://www.pythonware.com/daily/index.htm;) request.add_header(range, bytes=0-999) http_file = urllib2.urlopen(request) print http_file.headers[content-range] print len(http_file.read()) this prints: bytes 0-999/245105 1000 /F ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adding resume (206) support to urllib(2)
Martin v. Löwis wrote: given that urllib2 already supports partial requests, I'm not sure I see the point of reimplementing this on top of httplib. an example: import urllib2 request = urllib2.Request(http://www.pythonware.com/daily/index.htm;) request.add_header(range, bytes=0-999) But what does this do if the URL was a file URL, or an ftp URL? same thing as if you use range on a HTTP server that doesn't support ranges. you get all the data, and there's no content-range field in the response header. You have to know the syntax of the range header, and you have to know the syntax of the content-range header, to process it. With that, you can just as easily use httplib: I'm not sure as easily is the right way to describe something that requires more code but yet leaves out practical things as redirection support, host and user-agent headers, etc. /F ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] MSI being downloaded 10x more than all otherfiles?!
Guido van Rossum wrote: That was the month of October. If people believe these numbers are real, we're doing great!!! 2.5 was of course released in september, so I assume that part of what you're seeing is simply tinkerers upgrading their existing installations. plotting weekly figures for 2.4 and 2.5 over the last few months might give you a better idea of what the sustained download rate is, these days. (but we're definitely doing great. let there be no doubt about that ;-) /F ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [NPERS] Re: a feature i'd like to see in python #2: indexing of match objects
Talin wrote: Maybe instead of considering a match object to be a sequence, a match object should be considered a map? sure, except for one small thing. from earlier in this thread: Ka-Ping Yee wrote: I'd say, don't pretend m is a sequence. Pretend it's a mapping. Then the conceptual issues go away. to which I replied: almost; that would mean returning KeyError instead of IndexError for groups that don't exist, which means that the common pattern a, b, c = m.groups() cannot be rewritten as _, a, b, c = m which would, perhaps, be a bit unfortunate. /F ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [NPERS] Re: a feature i'd like to see in python #2: indexing of match objects
Talin wrote: The original proposal was to make m[n] a synonym for m.group(n). group() is clearly map-like in its behavior. so have you checked what exception m.group(n) raises when you try to access a group that doesn't exist ? frankly, speaking as the original SRE author, I will now flip the bikeshed bit on all contributors to this thread, and consider it closed. I'll post a patch shortly. /F ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] __str__ and unicode
M.-A. Lemburg wrote: This was added to make the transition to all Unicode in 3k easier: thanks for the clarification. do you recall when this was added? 2.5? /F ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [NPERS] Re: a feature i'd like to see in python #2: indexing of match objects
Michael Urman wrote: The idea that slicing a match object should produce a match object sounds like a foolish consistency to me. well, the idea that adding m[x] as a convenience alias for m.group(x) automatically turns m into a list-style sequence that also has to support full slicing sounds like an utterly foolish consistency to me. the OP's original idea was to make a common use case slightly easier to use. if anyone wants to argue for other additions to the match object API, they should at least come up with use cases based on real existing code. (and while you guys are waiting, I suggest you start a new thread where you discuss some other inconsistency that would be easy to solve with more code in the interpreter, like why -, /, and ** doesn't work for strings, lists don't have a copy method, sets and lists have different API:s for adding things, we have hex() and oct() but no bin(), str.translate and unicode.translate take different arguments, etc. get to work!) /F ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [NPERS] Re: a feature i'd like to see in python #2: indexing of match objects
Ben Wing wrote: i'm ok either way -- that is, either with the proposal i previously published, or with this restricted idea. ok, I'll whip up a patch for the minimal version of the proposal, if nobody beats me to it (all that's needed is a as_sequence struct with a item slot that basically just calls match_getslice_by_index). /F ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [NPERS] Re: a feature i'd like to see in python #2: indexing of match objects
Alastair Houghton wrote: (The current groups() method *doesn't* match those expectations, incidentally. I know I've been tripped up in the past because it didn't include the full match as element 0.) that's because there is no group 0 in a regular expression; that's just a historical API convenience thing. groups are numbered from 1 and upwards, and groups() returns all the actual groups. What's more, I think it will be confusing for Python newbies because they'll see someone doing m[3] and assume that m is a list-like object, then complain when things like for match in m: print match that'll work, of course, which might be confusing for people who think they understand how for-in works but don't ;) or m[3:4] fail to do what they expect. the problem with slicing is that people may 1) expect a slice to return a new object *of the same type* (which opens up a *gigantic* can of worms, both on the implementation level and on the wtf-is-this-thing- really level), and 2) expect things like [::-1] to work, which opens up another can of worms. I prefer the If the implementation is easy to explain, it may be a good idea. design principle over can of worms design principle. /F ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] LSB: Binary compatibility
Martin v. Löwis wrote: In any case, having Python in the LSB means that ISVs (software vendors) who target LSB (rather than targetting specific Linux distributions) could develop their applications also in Python (whereas now they have to use C or C++). ... without having to include a Python runtime. /F ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] DRAFT: python-dev summary for 2006-11-16 through 2006-11-30
Steven Bethard wrote: Fredrik Lundh has been working on a `new Python FAQ`_ footnote: working on cleaning up the old FAQ, to be precise. it'll end up on python.org, as soon as Andrew Kuchling gets around to complete his FAQ renderer (which may take a while, since he's busy with PyCon 2007). /F ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] a feature i'd like to see in python #2: indexing of match objects
Ka-Ping Yee wrote: I'd say, don't pretend m is a sequence. Pretend it's a mapping. Then the conceptual issues go away. almost; that would mean returning KeyError instead of IndexError for groups that don't exist, which means that the common pattern a, b, c = m.groups() cannot be rewritten as _, a, b, c = m which would, perhaps, be a bit unfortunate. taking everything into account, I think we should simply map __getitem__ to group, and stop there. no len(), no slicing, no sequence or mapping semantics. if people want full sequence behaviour with len and slicing and iterators and whatnot, they can do list(m) first. /F ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] a feature i'd like to see in python #2: indexing of match objects
Martin v. Löwis wrote: Several issues need to be taken into account: the most important issue is that if you want an object to behave as a sequence of something, you need to decide what that something is before you start tinkering with the syntax. under Ben's simple proposal, m[:][1] and m[1] would be two different things. I'm not sure that's a good idea, really. /F ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] a feature i'd like to see in python #2: indexing of match objects
Martin v. Löwis wrote: Ah, right; I misread his proposal as saying that m[:] should return [m[0]] + list(m.groups()) (rather, I expected that m.groups() would include m.group(0)). match groups are numbered 1..N, not 0..(N-1), in both the API and in the RE syntax (and we don't have much control over the latter). To answer your first question: it is clearly groups that you want to index, just as the .group() method indexes groups. so what should len(m) do? /F ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] a feature i'd like to see in python #2: indexing of match objects
Martin v. Löwis wrote: match groups are numbered 1..N, not 0..(N-1), in both the API and in the RE syntax (and we don't have much control over the latter). py m = re.match(a(b),ab) py m.group(0) 'ab' py m.group(1) 'b' 0 isn't a group, it's an alias for the full match. /F ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] a feature i'd like to see in python #2: indexing of match objects
Martin v. Löwis wrote: I know what the Zen says about special cases, but in this case the rules were apparently broken with impunity. Well, the proposal was to interpret m[i] as m.group(i), for all values of i. I can't see anything confusing with that. it can quickly become rather confusing if you also interpret m[:] as m.groups(), not to mention if you add len() and arbitrary slicing to the mix. what about m[] and m[i,j,k], btw? /F ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] a feature i'd like to see in python #2: indexing of match objects
Martin v. Löwis wrote: it can quickly become rather confusing if you also interpret m[:] as m.groups(), not to mention if you add len() and arbitrary slicing to the mix. what about m[] and m[i,j,k], btw? I take it that you are objecting to that feature, then? I haven't seen a complete and self-consistent proposal yet, so that's not easy to say. /F ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Small tweak to tokenize.py?
Guido van Rossum wrote: it would be a good thing if it could, optionally, be made to report horizontal whitespace as well. It's remarkably easy to get this out of the existing API sure, but it would be even easier if I didn't have to write that code myself (last time I did that, I needed a couple of tries before the parser handled all cases correctly...). but maybe this could simply be handled by a helper generator in the tokenizer module, that simply wraps the standard tokenizer generator and inserts whitespace tokens where necessary? keep track of the end position returned by the previous call, and if it's different from the start position returned by the next call, slice the line text from the column positions, assuming the line numbers are the same.If the line numbers differ, something has been eating \n tokens; this shouldn't happen any more with my patch. you'll still have to deal with multiline strings, right? /F ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] OT: World's oldest ritual discovered. Worshipped the python 70, 000 years ago
Frank Lomax wrote: The PSU does not, nor ever has existed. Any statement implying otherwise is false and subversive. There is no PSU and even if there is, it has no influence whatsoev it's a bit interesting that every time someone writes something along those lines, their computer's Power Supply Unit always gives up halfway through the last sentence ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python and the Linux Standard Base (LSB)
Martin v. Löwis wrote: Like I said, it's possible to split Python without making things complicated for newbies. You may have that said, but I don't believe its truth. For example, most distributions won't include Tkinter in the standard Python installation: Tkinter depends on _tkinter depends on Tk depends on X11 client libraries. Since distributors want to make X11 client libraries optional, they exclude Tkinter. So people wonder why they can't run Tkinter applications (search comp.lang.python for proof that people wonder about precisely that). comp.lang.python only represents a *very* tiny fraction of the python universe, though. I'd be much more interested in hearing from people tracking distribution-specific forums. I don't think the current packaging tools can solve this newbie problem. It might be solvable if installation of X11 libraries would imply installation of Tcl, Tk, and Tkinter: people running X (i.e. most desktop users) would see Tkinter installed, yet it would be possible to omit Tkinter. I think this is a way too python-centric view of things. maybe we could just ask distributors to prepare a page that describes what portions of the standard distribution they do include, and in what packages they've put the various components, and link to those from the library reference and/or the wiki or FAQ? is there perhaps some machine-readable format that could be used for this? /F ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] infinities
tomer filiba wrote: no, it requires *infinity* to accomplish x - y == x; y != 0, for example: while limit 0: limit -= len(chunk) with limit = posinf, the above code should be equivalent to while True. that's a remarkably stupid way to count bytes. if you want to argue for additions to the language, you could at least bother to come up with a sane use case. /F ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Distribution tools: What I would like to see
Talin wrote: But it isn't just the docs that are at fault here - otherwise, I'd be posting this on a different mailing list. It seems like the whole architecture is 'diff'-based, a series of patches on top of patches, which are in need of some serious refactoring. so to summarize, you want someone to rewrite the code and write new documentation, and since you didn't even have time to make your post shorter, that someone will obviously not be you ? /F ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] DRAFT: python-dev summary for 2006-11-01 to 2006-11-15
Armin Rigo wrote: Yuk! Not renamed to .py files. Distributing .py files that are actually bytecode looks like a new funny way to create confusion. No, I was half-heartedly musing about introducing Yet Another file extension (.pyc for caching and .pyX for importable bytecode, or possibly the other way around). an alternative would be to only support source-less PYC import from ZIP archives (or other non-filesystem importers). /F ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python in first-year MIT core curriculum
Ka-Ping Yee wrote: Wow. Did you catch this news? http://www-tech.mit.edu/V125/N65/coursevi.html The first four weeks of C1 will be a lot like the first four weeks of 6.001, Abelson said. The difference is that programming will be done in Python and not Scheme. This story was published on Wednesday, February 1, 2006. ;-) /F ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 2.5 portability problems
Martin v. Löwis wrote: I'd like to share an observation on portability of extension modules to Python 2.5: python-ldap would crash on Solaris, see http://groups.google.com/group/comp.lang.python/msg/a678a969c90f21ab?dmode=sourcehl=en It turns out that this was caused by a mismatch in malloc families (PyMem_Del vs. PyObject_Del): I was just hit *hard* by this issue (in an extension that worked perfectly well under all test cases, and all but one demo script, which happened to be the only one that happened to do a certain trivial operation more than 222 times), so I added a FAQ entry: http://effbot.org/pyfaq/why-does-my-c-extension-suddenly-crash-under-2.5.htm feel free to add symptoms or other observations for other platforms and/or extensions. cheers /F ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] PyFAQ: help wanted with thread article
(reposted from c.l.py) the following FAQ item talks about using sleep to make sure that threads run properly: http://effbot.org/pyfaq/none-of-my-threads-seem-to-run-why.htm I suspect it was originally written for the thread module, since as far as I know, the threading module takes care of the issues described here all by itself. so, should this item be removed? or can anyone suggest a rewrite that's more relevant for threading users? /F ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Passing floats to file.seek
Martin v. Löwis wrote: Patch #1067760 deals with passing of float values to file.seek; the original version tries to fix the current implementation by converting floats to long long, rather than plain C long (thus supporting files larger than 2GiB). I propose a different approach: passing floats to seek should be an error. My version of the patch uses the index API, this will automatically give an error. Two questions: a) should floats be supported as parameters to file.seek I don't really see why. b) if not, should Python 2.6 just deprecate such usage, or outright reject it? Python 2.5 silently accepts (and truncates) a float that's within range, so a warning sounds like the right thing to do for 2.6. note that read already produces such a warning: f = open(hello.txt) f.seek(1.5) f.read(1.5) __main__:1: DeprecationWarning: integer argument expected, got float 'e' /F ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] ready-made timezones for the datetime module
I guess I should remember, but what's the rationale for not including even a single concrete tzinfo implementation in the standard library? not even a UTC class? or am I missing something? /F ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] ready-made timezones for the datetime module
Martin v. Löwis wrote: I guess I should remember, but what's the rationale for not including even a single concrete tzinfo implementation in the standard library? not even a UTC class? or am I missing something? If you are asking for a time-zone database I was more thinking of basic stuff like the UTC, FixedOffset and LocalTimezone classes from the library reference: http://docs.python.org/lib/datetime-tzinfo.html I just wrote a small RSS generator; it took more more time to sort out how to get strftime(%z) to print something meaningful than it took to write the rest of the code. would anyone mind if I added the above classes to the datetime module ? /F ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] ready-made timezones for the datetime module
Guido van Rossum wrote: IMO it was an oversight. Or we were all exhausted. I keep copying those three classes from the docs, which is silly. :-) I'll whip up a patch. would the embedded python module approach I'm using for _elementtree be okay, or should this go into a support library ? /F ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] __dir__, part 2
Guido van Rossum wrote: No objection on targetting 2.6 if other developers agree. Seems this is well under way. good work! given that dir() is used extensively by introspection tools, I'm not sure I'm positive to a __dir__ that *overrides* the standard dir() behaviour. *adding* to the default dir() list is okay, re- placing it is a lot more questionable. (what about vars(), btw?) /F ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] __dir__, part 2
Guido van Rossum wrote: I think that ought to go into the guidlines for what's an acceptable __dir__ implementation. We don't try to stop people from overriding __add__ as subtraction either. to me, overriding dir() is a lot more like overriding id() than over- riding +. I don't think an object should be allowed to lie to the introspection mechanisms. /F ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Path object design
Martin v. Löwis wrote: Andrew Dalke schrieb: urlparse.urljoin(http://blah.com/;, ..) 'http://blah.com/' urlparse.urljoin(http://blah.com/;, ../) 'http://blah.com/../' urlparse.urljoin(http://blah.com/;, ../..) 'http://blah.com/' Does the result make sense to you? Does it make sense that the last of these is shorter than the middle one? It sure doesn't to me. I thought it was obvious that there was an error; That wasn't obvious at all to me. Now looking at the examples, I agree there is an error. The middle one is incorrect; urlparse.urljoin(http://blah.com/;, ../) should also give 'http://blah.com/'. make that: could also give 'http://blah.com/'. as I said, today's urljoin doesn't guarantee that the output is the *shortest* possible way to represent the resulting URI. /F ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Path object design
Steve Holden wrote: Ah, but how do you know when that's wrong? At least under ftp:// your root is often a mid-level directory until you change up out of it. http:// will tend to treat the targets as roots, but I don't know that there's any requirement for a /.. to be meaningless (even if it often is). I'm darned if I know. I simply know that it isn't right for http resources. the URI specification disagrees; an URI that starts with ../ is per- fectly legal, and the specification explicitly states how it should be interpreted. (it's important to realize that urijoin produces equivalent URI:s, not file names) /F ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Path object design
Steve Holden wrote: Although the last two smell like bugs, the point of urljoin is to make an absolute URL from an absolute (current page) URL also known as a base URL: http://www.w3.org/TR/html4/struct/links.html#h-12.4.1 (os.path.join's behaviour is also well-defined, btw; if any component is an absolute path, all preceding components are ignored.) /F ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Path object design
[EMAIL PROTECTED] wrote: I am not addressing this message to the py3k list because its general message of extreme conservatism on new features is more applicable to python-dev. However, py3k designers might also take note: if py3k is going to do something in this area and drop support for the legacy os.path, it would be good to choose something that is known to work and have few gotchas, rather than just choosing the devil we don't know over the devil we do. The weaknesses of os.path are at least well-understood. that's another reason why a new design might as well be defined in terms of the old design -- especially if the main goal is call-site convenience, rather than fancy new algorithms. /F ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Path object design
[EMAIL PROTECTED] wrote: I assert that it needs a better[1] interface because the current interface can lead to a variety of bugs through idiomatic, apparently correct usage. All the more because many of those bugs are related to critical errors such as security and data integrity. instead of referring to some esoteric knowledge about file systems that us non-twisted-using mere mortals may not be evolved enough to under- stand, maybe you could just make a list of common bugs that may arise due to idiomatic use of the existing primitives? I promise to make a nice FAQ entry out of it, with proper attribution. /F ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP: Extending the buffer protocol to share array information.
Chris Barker wrote: While /F suggested we get off the PIL bandwagon I suggest we drop the obsession with pointers to memory areas that are supposed to have a specific format; modern data access API:s don't work that way for good reasons, so I don't see why Python should grow a standard based on that kind of model. the right solution for things like this is an *API* that lets you do things like: view = object.acquire_view(region, supported formats) ... access data in view ... view.release() and, for advanced users format = object.query_format(constraints) /F ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Path object design
Talin wrote: I'm right in the middle of typing up a largish post to go on the Python-3000 mailing list about this issue. Maybe we should move it over there, since its likely that any path reform will have to be targeted at Py3K...? I'd say that any proposal that cannot be fit into the current 2.X design is simply too disruptive to go into 3.0. So here's my proposal for 2.6 (reposted from the 3K list). This is fully backwards compatible, can go right into 2.6 without breaking anything, allows people to update their code as they go, and can be incrementally improved in future releases: 1) Add a pathname wrapper to os.path, which lets you do basic path algebra. This should probably be a subclass of unicode, and should *only* contain operations on names. 2) Make selected shutil operations available via the os name- space; the old POSIX API vs. POSIX SHELL distinction is pretty irrelevant. Also make the os.path predicates available via the os namespace. This gives a very simple conceptual model for the user; to manipulate path *names*, use os.path.op(string) functions or the path wrapper. To manipulate *objects* identified by a path, given either as a string or a path wrapper, use os.op(path). This can be taught in less than a minute. With this in place in 2.6 and 2.7, all that needs to be done for 3.0 is to remove (some of) the old cruft. /F ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP: Extending the buffer protocol to share array information.
Terry Reedy wrote: I believe that at present PyGame can only work with external images that it is programmed to know how to import. My guess is that if image source program X (such as PIL) described its data layout in a way that NumPy could read and act on, the import/copy step could be eliminated. I wish you all stopped using PIL as an example in this discussion; for PIL 2, I'm moving towards an entirely opaque data model, with a data view-style client API. /F ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 355 status
Talin wrote: You probably want to use the posixpath module directly in that case, though perhaps you've already discovered that. Never heard of it. Its not in the standard library, is it? I don't see it in the table of contents or the index. http://effbot.org/librarybook/posixpath.htm /F ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Hunting down configure script error
[EMAIL PROTECTED] wrote: I'm not sure what a pebkac problem is. http://en.wikipedia.org/wiki/PEBKAC You'll learn some new nonsense every day ;-) /F ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] The lazy strings patch
Josiah Carlson wrote: It would be a radical change for Python 2.6, and really the 2.x series, likely requiring nontrivial changes to extension modules that deal with strings, and the assumptions about strings that have held for over a decade. the assumptions hidden in everyone's use of the C-level string API is the main concern here, at least for me; radically changing the internal format is not a new idea, but it's always been held off because we have no idea how people are using the C API. /F ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] The lazy strings patch
Larry Hastings wrote: Am I correct in understanding that changing the Python minor revision number (2.5 - 2.6) requires external modules to recompile? not, in general, on Unix. it's recommended, but things usually work quite well anyway. /F ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 2.4.4: backport classobject.c HAVE_WEAKREFS?
Larry Hastings wrote: I knocked out a prototype of this last week, emailed Mr. Lundh about it, then forgot about it. It's on my TODO list, so I haven't forgotten about it, but I've been (as usual) busy with other stuff. I'll get there, sooner or later. Posting this to the patch tracker and posting a note to the Py3K mailing list could be a good idea. /F ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] The lazy strings patch
Talin wrote: Interesting - is it possible that the same technique could be used to hide differences in character width? Specifically, if I concatenate an ascii string with a UTF-32 string, can the up-conversion to UTF-32 also be done lazily? of course. and if all you do with the result is write it to an UTF-8 stream, it doesn't need to be done at all. this requires a slightly more elaborate C-level API interface than today's PyString_AS_STRING API, though... (which is why this whole exercise belongs on the Python 3000 lists, not on python-dev for 2.X) /F ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 2.3.6 for the unicode buffer overrun
Martin v. Löwis wrote: In 2.3.6, there wouldn't just be that change, but also a few other changes that have been collected, some relevant for Windows as well why not just do a 2.3.5+security source release, and leave the rest to the downstream maintainers? /F ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 2.3.6 for the unicode buffer overrun
Anthony Baxter wrote: why not just do a 2.3.5+security source release, and leave the rest to the downstream maintainers? I think we'd need to renumber it to 2.3.6 at least, otherwise there's the problem of distinguishing between the two. I'd _hope_ that all the downstreams will have picked up the patch (if you know of someone who hasn't, let me know and I'll kick them for you if it would help). in my experience, downstream builders tend to deal with patches just fine; I'm more worried about people who build directly from tarballs (using the good old wget, tar xvfz, configure, make mental macro) But I'm certainly thinking if there's a 2.3.6, it's going to be 2.3.5 with the email fix and the unicode repr() fix, and that's it. sounds good to me. how much work would that be, and if you're willing to coordinate, is there anything we can do to help? /F ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 2.3.6 for the unicode buffer overrun
Brett Cannon wrote: I know AMK was experimenting with rest2web as a possible way to do the web site. There has also been talk about trying out another system. But I also know some people would rather put the effort into improving Pyramid. You forgot the ponies! Once again, it's a matter of people putting the time in to make a switch happen to a system that the site maintainers would be happy with. The people behind the current system and process has invested way too much energy and prestige in the current system to ever accept that the result is pretty lousy as a site, and complete rubbish as technology. It's about sunk costs, not cost- and time-effective solutions. For reference, here's my effbot.org release procedure: 1) upload the distribution files one by one, as soon as they're available. all links and stuff will appear automatically 2) update the associated description text through the web, when necessary, as an HTML fragment. click save to publish. 3) mail out an announcement when everything looks good. Maybe I should offer Anthony to do the releases via effbot.org instead? /F ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 2.3.6 for the unicode buffer overrun
Anthony Baxter wrote: The other thing to watch out for is that I (or whoever) can still do local work on a bunch of different files the point of my previous post is that you *shouldn't* have to edit a bunch of different files to make a new release. /F ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Why spawnvp not implemented on Windows?
Alexey Borzenkov wrote: P.S. Although it's a bit stretching, one might also say that implementing spawn*p* on windows is not actually a new feature, and rather is a bugfix for misfeature. Why every other platform can benefit from spawn*p* and only Windows can't? This just makes os.spawn*p* useless: it becomes unreliable and can't be used in portable code at all. any reason you cannot just use the subprocess module instead, like everyone else? /F ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 2.3.6 for the unicode buffer overrun
Anthony Baxter wrote: For reference, here's my effbot.org release procedure: 1) upload the distribution files one by one, as soon as they're available. all links and stuff will appear automatically 2) update the associated description text through the web, when necessary, as an HTML fragment. click save to publish. 3) mail out an announcement when everything looks good. Maybe I should offer Anthony to do the releases via effbot.org instead? First off - I'm not going to be posting 10M or 16M files through a web-browser. That's insane :-) oh, I only edit the pages through the web, not the files. there's nothing wrong with scp or sftp or rsync-over-ssh or whatever you're using today. The bit of the website that's dealing with the actual files is not the tricky bit - I have a dinky little python script that generates the download table. yeah, but *you* are doing it. if the server did that, Martin and other trusted contributors could upload the files as soon as they're available, instead of first transferring them to you, and then waiting for you to find yet another precious time slot to spend on this release. The problems are with the other bits of the pages. I keep thinking next release, I'll automate it further, but never have time on the day. that's why you have to have an overall infrastructure that lets you make incremental tweaks to the tool chain, so things can get a little better all the time. Pyramid obviously isn't such a system. /F ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 2.4.4: backport classobject.c HAVE_WEAKREFS?
Nick Coghlan wrote: would collapse to static PyTypeObject NoddyType; Wouldn't that have to be a pointer to allow the Python runtime complete control of the structure size without recompiling the extension?: static PyTypeObject *NoddyType; yeah, that's a silly typo. or maybe I was thinking of something really clever that I can no longer remember. NoddyType = PyType_Alloc(noddy.Noddy); if (!NoddyType) return; the fewer places you have to check for an error, the less chance you have to forget to do it. my proposal implied that the NULL check should be done in Ready. I've posted slightly cleaned up version of my rough proposal here: http://effbot.org/zone/idea-register-type.htm /F ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Why spawnvp not implemented on Windows?
Alexey Borzenkov wrote: any reason you cannot just use the subprocess module instead, like everyone else? Oh! Wow! I just simply didn't know of its existance (I'm pretty much new to python), and both distutils and SCons (I was looking inside them because they are major build systems and surely had to execute compilers somehow), and upon seeing that each of them invented their own method of searching path created a delusion as if inventing custom workarounds was the only way... Sorry... x_x no problem. someone should really update the documentation to make sure that os.spawn and os.open and commands and popen2 and all the other 80%-solutions at least point to the subprocess module... (and if the library reference had been stored in a wiki, I'd fixed that before any- one else even got this mail...) /F ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 2.3.6 for the unicode buffer overrun
Anthony Baxter wrote: 16 releases in 12 months would just about make me go crazy. is there any way we could further automate or otherwise streamline or distribute the release process ? ideally, releasing (earlier release + well-defined patch set) should be fairly trivial, compared to releasing (new release from trunk). what do we have to do to make it easier to handle that case? /F ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Cloning threading.py using proccesses
Greg Ewing wrote: Fredrik Lundh wrote: marshal hasn't changed in many years: Maybe not, but I was given to understand that it's regarded as a private format that's not guaranteed to remain constant across versions. So even if it happens not to change, it wouldn't be wise to rely on that. but given that the format *has* been stable for many years, surely it would make more sense to just codify that fact, rather than developing Yet Another Serialization Format instead? /F ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 2.4.4: backport classobject.c HAVE_WEAKREFS?
Martin v. Löwis wrote: Of course, if everybody would always recompile all extension modules for a new Python feature release, those flags weren't necessary. a dynamic registration approach would be even better, with a single entry point used to register all methods and hooks your C extension has implemented, and code on the other side that builds a properly initialized type descriptor from that set, using fallback functions and error stubs where needed. e.g. the impossible-to-write-from-scratch NoddyType struct initialization in http://docs.python.org/ext/node24.html would collapse to static PyTypeObject NoddyType; ... NoddyType = PyType_Setup(noddy.Noddy, sizeof(Noddy)); PyType_Register(NoddyType, PY_TP_DEALLOC, Noddy_dealloc); PyType_Register(NoddyType, PY_TP_DOC, Noddy objects); PyType_Register(NoddyType, PY_TP_TRAVERSE, Noddy_traverse); PyType_Register(NoddyType, PY_TP_CLEAR, Noddy_clear); PyType_Register(NoddyType, PY_TP_METHODS, Noddy_methods); PyType_Register(NoddyType, PY_TP_MEMBERS, Noddy_members); PyType_Register(NoddyType, PY_TP_INIT, Noddy_init); PyType_Register(NoddyType, PY_TP_NEW, Noddy_new); if (PyType_Ready(NoddyType) 0) return; (a preprocessor that generated this based on suitable macro decorators could be implemented in just over 8 lines of Python...) with this in place, we could simply remove all those silly NULL checks from the interpreter. /F ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 2.4.4: backport classobject.c HAVE_WEAKREFS?
I wrote: PyType_Register(NoddyType, PY_TP_METHODS, Noddy_methods); methods and members could of course be registered to, so the implementation can chose how to store them (e.g. short lists for smaller method lists, dictionaries for others). /F ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Cloning threading.py using proccesses
Greg Ewing wrote:
if you're aware of a way to do that faster than the current marshal
implementation, maybe you could work on speeding up marshal instead?
Even if it weren't faster than marshal, it could still
be useful to have something nearly as fast that used
a python-version-independent protocol.
marshal hasn't changed in many years:
$ python1.5
x = 1, 2.0, three, [4, 5, 6, seven], {8: 9}, None
import marshal
marshal.dump(x, open(x.dat, w))
$ python2.5
import marshal
marshal.load(open(x.dat))
(1, 2.0, 'three', [4, 5, 6, 'seven'], {8: 9}, None)
which is a good thing, because there are external non-Python tools that
generate marshalled data streams.
maybe you were thinking about marshalled code objects?
/F
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] Sky pie: a var keyword
I forgot the import statement (especially the * version) not only that, you also forgot what mailing list you were posting to... /F ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proprietary code in python?
Neal Becker [EMAIL PROTECTED] wrote: http://www.google.com/codesearch?q=+doc:DxlBcBw4TXo+proprietary+confidential+show:DxlBcBw4TXo:BwgQSUaGDCc:1s0hP8rbIGEsa=Ncd=1ct=rics_p=http://www.python.org/download/releases/binaries-1.3/python-IRIX-5.3-full.tar.gzcs_f=lib/python/irix5/AWARE.py#a0 that's most likely code that's been automatically generated from corresponding header files in IRIX. in most jurisdictions, laws about corporate secrets doesn't apply to things that you've intentionally published. (their file is still copyrighted, but I'm not sure to what extent you can use copyright to protect a few integers). /F ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
