> (there's still a possibility that someone checks in a fix without realizing
> that
> the original bug is an attack vector, but I don't think Coverity has
> discovered
> anything like that in the Python code base; we're mainly talking about leaks
> and null-pointer references here).
to clarify,
>> > return=NULL; output=junk => out of memory
>> > return=junk; output=-1 => cannot do this
>> > return=pointer; output=value => did this, returned value bytes
>>
>> > I agree that the design is a bit questionable;
>>
>> It sure is. If you get both NULL and -1 returned, how are
>> you
Martin v. Löwis wrote:
> Jean-Paul Calderone wrote:
> > It should actually be using TerminateProcess (depending on the
> > Twisted version being used, the relevant code is either in
> > twisted/internet/_dumbwin32proc.py or
> > twisted/internet/win32eventreactor.py, in the signalProcess method in
the definition of sys.executable is a bit unclear, something that has led to
incompatible use in deployed code.
the docstring for sys.executable says "pathname of this Python interpreter",
which can be interpreted as either
a) sys.executable points to the executable that was used to load the
Guido van Rossum wrote:
> For finding related files, sys.exec_prefix and sys.prefix should be used
except that they're defined in terms of where the standard library is:
prefix -- prefix used to find the Python library
exec_prefix -- prefix used to find the machine-specific Python librar
> > > a) sys.executable points to the executable that was used to load the
> > > Python interpreter library/dll.
> > >
> > > this use is supported by the docstring and the implementation, and is
> > > quite
> > > common in the wild. an application using this interpretation may
Th
Fred L. Drake, Jr. wrote:
> Fredrik Lundh wrote:
> > d) If Python was started from a standard Python interpreter,
>
> My understanding matches Guido's description, so I'm not sure any changes are
> needed.
the problem with that is that your understanding doesn
Wolfgang Langner wrote:
> today I got my first real python bug. Problem is described in:
>
> Bug with ID: 1184112
>
> http://sourceforge.net/tracker/index.php?func=detail&aid=1184112&group_id=5470&atid=105470
>
> I use python 2.3.5 in an embedded C++ Application which uses function:
> PyRun_Simple
Neal Norwitz wrote:
> Just in case anybody here's been snoozing, 2.5 alpha 1 is coming up
> real quick, hopefully within a couple of weeks. If you have any
> *major* features (particularly implemented in C) that you want to see
> in 2.5, bring it up now. I want to strive for feature completeness
Michael Hudson wrote:
> > The ssize_t patch is the single most disruptive patch in
> > Python 2.5, so it deserves special attention.
>
> From your POV, maybe: from mine, it's definitely the new compiler.
in what way does the new compiler affect third-party developers ?
__
M.-A. Lemburg wrote:
> Here's a grep of all the changed/new APIs, please include it
> in the PEP.
I've posted a simple-minded source scanner here:
http://svn.effbot.python-hosting.com/stuff/sandbox/python/ssizecheck.py
___
Python-Dev mailing list
M.-A. Lemburg wrote:
> Perhaps we should have three lists:
>
> 1. Py_ssize_t output parameters (these need changes)
> 2. Py_ssize_t return values (these need overflow checks)
> 3. Py_ssize_t input parameters (these can be used to enhance
>the extension)
>
> Here's the list for 2 (I already pro
Martin v. Löwis wrote:
> There are two improvements you could make:
> - Some of the functions in the first list return Py_ssize_t; calling
>them can cause truncation if the result value is larger than INT_MAX
>(and it is assigned to an int). To find those functions, do
>grep 'PyAPI_FUN
neal.norwitz wrote:
> +Outstanding Issues
> +==
> +
> +* Require C99, so we can use // comments, named initializers, declare
> variables
> + without introducing a new scope, among other benefits.
gcc only, in other words ?
> +* Remove support for old systems, including: OS2, Be
Michael Hudson wrote:
> >> +* Remove support for old systems, including: OS2, BeOS, RISCOS, (SGI)
> >> Irix, Tru64
> >
> > what's old with tru64 ? it's not that uncommon in places where Python
> > has a strong presence, you can still buy AXP hardware throughout 2006,
> > and HP says they'll keep
Gerhard Häring wrote:
> I know that pushing new things into Python 2.5 should happen soon, if at
> all. So *if* pysqlite should go into Python, I propose that I release
> pysqlite 2.2.0 and we integrate that into the Python alpha release.
+1 !
> If this is going to happen, I want it to happen un
Anthony Baxter wrote:
> > > db.sqlite3 ?
> >
> > That would make sense if inclusion of more database-related modules
> > was planned.
>
> My only concern about this is that it wouldn't be possible for other
> authors to provide 3rd party packages as (for instance) db.mysqldb
> because of the way p
Georg Brandl wrote:
> Generally, I like Trac very much, especially for its interconnected
> subsystems.
> I've used it with smaller projects, and there it works perfectly.
> Having said that, I don't know if the Trac ticket system (which would be the
> most important subsystem for us) scales up
Guido van Rossum wrote:
> Watch out for the parochialism! I like Python as much as the next guy
> (probably more :-) but I'm sensitive to choosing the best solution.
you better make that "good enough", or we'll be stuck with SF for an-
other hundred years.
> The language choice should only be us
Robert Brewer wrote:
> More Against?:
> Explaining "database is locked" errors (due to SQLite's exposed
> multiple-readers/one-writer design) on a daily basis (FAQ entries
> notwithstanding).
wow. that's one quality argument. what's wrong with you ?
Guido van Rossum wrote:
> Unless you've recanted on that already, let me point out that I've
> never seen sqlite, and I've ignored this thread, so I don't know what
> the disagreement is all about.
what disagreement ?
sqlite is a widely used light-weight SQL library (http://www.sqlite.org)
that'
> gerald's pysqlite binding
sorry, gerhard.
___
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
[EMAIL PROTECTED] wrote:
> I haven't been tracking the pysqlite discussion either, but one con you
> missed is that regardless of pro #1 people will almost certainly apply it to
> problems for which it is ill-suited, reflectly poorly on both Python and
> SQLite.
the arguments keep getting more an
Brett Cannon wrote:
> > Wouldn't the newly founded python-3000 mailing list be the perfect place
> > for such major changes?
>
> If you go back and look at Guido's Python 3000 Process email he said
> that the change could occur in 2.6 and then be done for 3000.
> Renaming modules is not that hard
Bill Janssen wrote:
> On the package naming issue: using "em" for "email" would be wrong,
> just as "db" for "database" would be wrong.
are you aware of the fact that the module implements the "db-api" ?
___
Python-Dev mailing list
Python-Dev@pytho
Greg Ewing wrote:
> Firebird could be a solution to this. It can be
> used in a mode that doesn't need a server, and it
> has no trouble at all with concurrency or large
> amounts of data that I know of.
so a library that doesn't support multiple independent readers/writers on
a single file at al
Neal Norwitz wrote:
> I'm in favor of having Atlassian setup a system to be used for 3k. It
> would be completely experimental and could be completely thrown away
> which should be made clear to Atlassian if we were to do this. I
> would use the system for evaluation.
so what's the advantage of
Greg Ewing wrote:
>> > Firebird could be a solution to this.
>>
>> so a library that doesn't support multiple independent
> > readers/writers on a single file at all is much better
> > than one that does,
>
> Where do you get that from? Firebird supports
> multiple readers/writers perfectly well.
Anthony Baxter wrote:
>> xml.dom.minidom?
>
> given the horror of _xmlplus/xmlcore and whatnot, I'd be hesitant to
> use the xml package as an example of _anything_
which reminds me -- is that issue still open ? martin? fred?
___
Python-Dev mai
Anthony Baxter wrote:
> It looks to me like it's fixed in SVN.
>
> http://mail.python.org/pipermail/python-dev/2005-December/058710.html
the issue isn't the one in that message though; it's the one in this message:
http://mail.python.org/pipermail/python-dev/2005-December/058752.html
"I
Georg Brandl wrote:
> What I answered to was:
>
> """
> from what I can tell, no big contemporary Python project use Atlassian.
> they all use Trac. there are thousands of Python developers out there
> that are used to working with Trac.
>
> I'm obviously missing something here.
> """
>
> I'm not
Anthony Baxter wrote:
> > Such a module name is less likely to cause problems.
>
> Excellent point. Hm. Maybe we should just go with 'sqlite', instead.
except that "sqlite" was the name used by the first pysqlite
generation:
$ python2.3
>>> import sqlite
>>> sqlite.version
'1.1.6'
I'm not sure
Martin v. Löwis wrote:
> > I'm obviously missing something here.
>
> One thing that you are *obviously* missing (there might be more):
>
> Nobody has stepped forward and said "I make trac happen". Without
> somebody (specific) saying that, all technical arguments in favour
> of that software are f
Brett Cannon wrote:
> Same here. Please move any more comments about infrastructure to the
> infrastructure list
> (http://mail.python.org/mailman/listinfo/infrastructure/). But
> do realize the committee is not discussing trackers yet. We are still
> trying to get our SF data out so that can
Tim Peters wrote:
> [Georg Brandl]
> > for the Bug Day, someone asked me if there is a prebuilt trunk
> > for Windows available somewhere so that he could participate.
> >
> > Martin: I read you've built for a snapshot AMD64, is there one for x86 too?
>
> If someone can explain what "prebuilt trun
Guido van Rossum wrote:
> > > I can ask them for a test py3k account, if there's any interest.
> >
> > I'm personally not very much interested in a Py3k tracker; I don't
> > see myself using it. So I'm not interested in a trac-based one,
> > either.
>
> Me neither. It's too early.
I wasn't really
Robert Kern wrote:
> Apologies: for the other blank reply.
oh, I don't know about that -- the eco quote made perfect sense ;-)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http:/
Martin v. Löwis wrote:
> That isn't actually worth that much: somebody would need to operate it,
> too. Mere existence doesn't help.
why do you keep repeating this when I've already posted a link to a
company that does this for only a few bucks per month ?
___
Brett Cannon wrote:
> > oh, I forgot that the Procrastination & Stop energy Foundation was involved
> > in this.
> Fredrik, if you would like to help move this all forward, great; I
> would appreciate the help. You can write a page scraper to get the
> data out of SF if you don't believe SF will
Brett Cannon wrote:
> > oh, I forgot that the Procrastination & Stop energy Foundation was involved
> > in this.
>
> Fredrik, if you would like to help move this all forward, great; I
> would appreciate the help. You can write a page scraper to get the
> data out of SF
challenge accepted ;-)
ht
Georg Brandl wrote:
> it's time for the 7th Python Bug Day. The aim of the bug day is to close
> as many bugs, patches and feature requests as possible, this time with a
> special focus on new features that can still go into the upcoming 2.5 alpha
> release.
so, how did it go? a status report /
> > Fredrik, if you would like to help move this all forward, great; I
> > would appreciate the help. You can write a page scraper to get the
> > data out of SF
>
> challenge accepted ;-)
>
> http://effbot.python-hosting.com/browser/stuff/sandbox/sourceforge/
>
> contains three basic tools; getind
Martin v. Löwis wrote:
> Yes. We found a way to export all data (except for file attachments),
> through a different exporter. This gives all data, unfortunately, it
> is ill-formed XML (& is not properly entity-referenced sometimes).
so why didn't Brett know about this ?
> Anybody who wants to
> the source code is available via the above link; I'll post the ZIP file some-
> where tomorrow (drop me a line if you want the URL).
I found some free space on the effbot.org server, so anyone inter-
ested can get the current ZIP file here:
http://effbot.org/tracker-20060403.zip
the zip fi
Thomas Wouters wrote:
> The webpage should be made, though, if just to refer to in the
> release notes.
the web page does exist:
http://www.python.org/dev/peps/pep-0353/#conversion-guidelines
___
Python-Dev mailing list
Python-Dev@python.org
h
Bob Ippolito wrote:
> > Try the 2.5 alpha 1 just released, and you'll see that the toplevel
> > package is now xml.etree. The module and class are still called
> > ElementTree, though.
>
> It would be nice to have new code be PEP 8 compliant..
it's not new code, and having *different* module nam
Trent Mick wrote:
> That is the current state.
which reminds that maybe it's time to add an import helper to
the standard library, so you can do
stringio = import_search("cStringIO", "StringIO")
ET = import_search("lxml.etree", "cElementTree", "xml.etree.cElementTree")
db = import_se
Anthony Baxter wrote:
> This is from bug www.python.org/sf/1465408
>
> Because the Python.asdl and the generated Python-ast.[ch] get checked
> into svn in the same revision, the svn export I use to build the
> tarballs sets them all to the same timestamp on disk (the timestamp
> of the checkin). "
Tim Peters wrote:
> Just do it. Branches under SVN are cheap, go fast, and are pretty
> easy to work with. Even better, because a branch is just another
> named directory in SVN's virtual file system, you can "svn remove" it
> when you're done with it (just like any other directory).
footnote:
Phillip J. Eby wrote:
> Your proposals, however, generally favor experts at the expense of the
> average user, and treat it as axiomatic that the benefits provided by
> setuptools are not worth having, no matter how small the cost.
mal's arguing from well-established Python design principles (imp
Neal Norwitz wrote:
> I was also working under the assumption that people would complain if
> they didn't like something. What do people think should happen for
> the "Possible features" section? Should I ask if there are any
> objections to each item?
some discussion on python-dev for each non
Phillip J. Eby wrote:
> I was surprised that MAL didn't comment *then*, actually, and mistakenly
> thought it meant that our last discussion on the distutils-sig (and my
> attempts to deal with the problems) had been successful. Between that and
> MvL's mild response to the explicit discussion of
Phillip J. Eby wrote:
> The long term plan is for a tool called "nest" to be offered, which will
> offer a command-line interface similar to that of the "yum" package
> manager, with commands to list, uninstall, upgrade, and perform other
> management functions on installed packages.
yum already
Anthony Baxter wrote:
> I'm not sure how people would prefer this be handled. I don't think we
> need to have a PEP for it - I don't see PEPs for ctypes, elementtree,
> pysqlite or cProfile, either.
That's because they're all trivial building blocks, not all-consuming world
views. Any programmer
Martin v. Löwis wrote:
> It is *precisely* my concern that this happens. For whatever reason,
> writing packaging-and-deployment software is totally unsexy.
for some reason, tools of this kind tend to reach the big ball of mud stage
even before they reach the dogfood stage. and once you have a b
Phillip J. Eby wrote:
> >a technical document that, in full detail, describes the mechanisms *used* by
> >setuptools, including what files it creates, what the files contain, how
> >they are used during import, how non-setuptools code can manipulate (or at
> > least inpect) the data, etc, setuptoo
Anthony Baxter wrote:
> > http://www.joelonsoftware.com/articles/fog69.html
>
> Yes. I remember that piece. In particular, he wrote the original rant
> about this about Mozilla/Firefox. How did that work out again? Oh,
> that's right - we now have a much, much more successful and usable
>
Anthony Baxter wrote:
> - Multiple installs of different versions of the same package,
> including per-user installs.
yeah, but where is the documentation on how this works ? phillip points
to a 30-page API description, which says absolutely nothing whatsoever
about the files I'm going to find o
Andrew Clover wrote:
> Morning!
>
> I've done some tweaks to the previously-posted-about icon set, taking
> note of some of the comments here and on -list.
you do wonderful stuff, and then you post the announcement as a
followup to a really old message, to make sure that people using a
threaded r
Anthony Baxter wrote:
> I also don't think it will be the "death" of distutils. I think that
> over time the two pieces of code will become closer together -
> hopefully for Python 3.0 we can formally merge the two.
I was hoping that for Python 3.0, we could get around to unkludge the
sys.path/me
Greg Ewing wrote:
> Fredrik Lundh wrote:
>
> > (distutils and setuptools are over 15000 lines of code, according to sloc-
> > count.
>
> Ye cats! That's a *seriously* big ball of mud. I just checked,
> and the whole of Pyrex is only 17000 lines.
correction: it&
"Guido van Rossum wrote:
> > - I still fear that the code of setuptools will turn out to be
> > a maintenance nightmare.
>
> AFAICT Phillip has explicitly promised he will maintain it (or if he
> doesn't, I expect that he would gladly do so if you asked). This has
> always been sufficient as a "
A.M. Kuchling wrote:
> The 2.1 requirement was originally imposed because Greg Ward would
> make standalone Distutil releases. Greg is too busy working at his
> job, going camping on weekends, and being best man [1] to make new
> releases these days.
from python-announce:
From: Greg Ward
Brett Cannon wrote:
> > Not sure whether Fredrik Lundh has responded, but I believe he once
> > said that he would prefer if ElementTree isn't directly modified, but
> > that instead patches are filed on the SF tracker and assigned to him.
>
> Nope, Fredrik neve
Thomas Heller wrote:
> I'm about to import the 0.9.9.6 tag of ctypes into Python svn.
>
> Should this be done in exact the same way as before, so first
> commit it into external/ctypes-0.9.9.6, and then 'svn copy'
> the two relevant directories into the trunk, and afterwards set
> all the svn prop
[EMAIL PROTECTED] wrote:
> Maybe they know something we don't.
oh, please. it's not like people like myself and MAL don't know anything
about package distribution...
(why is it that people who *don't* distribute stuff are a lot more im-
pressed by a magic tool than people who've spent the last
Ian Bicking wrote:
> And now for a little pushback the other way -- as of this January
> TurboGears has served up 100,000 egg files (I'm not sure what the window
> for all those downloads is, but it hasn't been very long). Has it
> occurred to you that they know something you don't about distribu
Phillip J. Eby wrote:
> The problem isn't fundamentally a technical one, but a social one. You can
> effect social change through technology, but not by being some random guy
> with a nagging 'bot.
> Seriously, though, posting Cheesecake scores (which include ratings for
> findability of code, u
Terry Reedy wrote:
> 1. Based on comments on c.l.py, the biggest legitimate fact-based (versus
> personal-taste-based) knock again Python versus, in particular, Perl is the
> lack of a CPAN-like facility. As I remember, there have even been a few
> people say something like "I like Python the lan
Guido van Rossum wrote:
> Leaving aside the Perl vs. Py thing, opinions on CPAN seem to be
> diverse -- yes, I've heard people say that this is something that
> Python sorely lacks; but I've also heard from more than one person
> that CPAN sucks from a quality perspective. So I think we shouldn't
Ian Bicking wrote:
> For instance, if you really want to be confident about how your libraries
> are layed out, this script is the most reliable way:
> http://peak.telecommunity.com/dist/virtual-python.py
note the use of "this script is the most reliable way", not "something
like this script", or
Guido van Rossum wrote:
> Nick, please get unstuck on the "who said what when and who wasn't
> listening" thing. I want this to be resolved to use the clearest
> terminology possible.
which probably means that the words "context" and "manager" shouldn't
be used at all ;-)
"space" and "potato", p
Phillip J. Eby wrote:
> >(frankly, do you think there's any experienced developer out there
> >whos first thought when asked the question "how do I create a tightly
> >controlled Python environment" isn't either "can I solve this by tweaking
> >sys.path in my application?" or "disk space is cheap,
Guido van Rossum wrote:
> So I have a very simple proposal: keep the __init__.py requirement for
> top-level pacakages, but drop it for subpackages. This should be a
> small change. I'm hesitant to propose *anything* new for Python 2.5,
> so I'm proposing it for 2.6; if Neal and Anthony think this
the pytut wiki (http://pytut.infogami.com/) has now been up and
running for one month, and has seen well over 250 edits from over
a dozen contributors.
to celebrate this, and to exercise the toolchain that I've deve-
loped for pytut and pyfaq (http://pyfaq.infogami.com/), I spent
a few hours putti
Josiah Carlson wrote:
> At least for the examples of buffers that I've seen, using the buffer
> interface for objects that support it is equivalent to automatically
> applying str() to them. This is, strictly speaking, an optimization.
>>> a = array.array("i", [1, 2, 3])
>>> str(a)
"
trying to come up with a more concise description of the rich
comparision machinery for pyref.infogami.com, I stumbled upon
an oddity that I cannot really explain:
in the attached example below, why is the rich comparision
machinery doing *four* attempts to use __eq__ in the old-
class case?
$
Brett Cannon wrote:
> ElementTree
> ---
> - Web page
> http://effbot.org/zone/element-index.htm
> - Standard library name
> xml.etree
> - Contact person
> Fredrik Lundh
> - Synchronisation history
> * 1.2.6 (2.5)
xml.etree contains components
Guido van Rossum wrote:
> I believe the context API design has gotten totally out of hand.
> I have a counter-proposal: let's drop __context__.
Heh. I was about to pull out the "if the implementation is hard to
explain, it's a bad idea (and bad ideas shouldn't go into 2.X)" rule
last week in resp
Guido van Rossum wrote:
> Things should be as simple as possible but no simpler. It's pretty
> clear to me that dropping __context__ approaches this ideal. I'm sorry
> I didn't push back harder when __context__ was first proposed -- in
> retrospect, the first 5 months of PEP 343's life, before __c
Terry Reedy wrote:
> My "Why?" was and is exactly a request for that further discussion.
>
> Again: if a function has a fixed number n of params, why say that the first
> k can be passed by position, while the remaining n-k *must* be passed by
> name?
have you designed API:s for others than yours
Greg Ewing wrote:
> I've been thinking about the terms "guarded context"
> and "context guard". We could say that the with-statement
> executes its body in a guarded context (an abstract
> notion, not a concrete object). To do this, it creates
> a context guard (a concrete object) with __enter__
>
Edward Loper wrote:
> > One reason I see is to have keyword-only functions, i.e. with no
> > positional arguments at all:
> >
> > def make_person(*, name, age, phone, location):
> > pass
> >
> > which also works for methods:
> >
> > def make_person(self, *, name, age, phone, location):
> >
Nick Coghlan wrote:
> I've called that the "context entry value" in a few places (I don't think any
> of them were in the actual documentation though).
that doesn't really give me the right associations (I want something
that makes it clear that this is an "emphemeral" object).
> A sample modifi
Martin v. Löwis wrote:
> > I.e., why not just document that the arguments should
> > be used as keyword arguments, and leave it at that.
>
> Because they wouldn't be keyword-only arguments, then.
which reminds me of the following little absurdity gem from the language
reference:
The followin
Terry Reedy wrote:
> And again, why would you *make* me, the user-programmer, type
>
> make_person(name=namex, age=agex, phone=phonex, location = locationx)
> #instead of
> make_person(namex,agex,phonex,locationx)
> ?
because a good API designer needs to consider more than just the current
releas
Edward Loper wrote:
> >> And again, why would you *make* me, the user-programmer, type
> >>
> >> make_person(name=namex, age=agex, phone=phonex, location = locationx)
> >> #instead of
> >> make_person(namex,agex,phonex,locationx)
> >> ?
> >
> > because a good API designer needs to consider more th
the language reference says:
continue may only occur syntactically nested in a for or while loop,
but not nested in a function or class definition or finally statement
within that loop. /.../
It may occur within an except or else clause. The restriction on occurring
in the try
A.M. Kuchling wrote:
> I find this work very exciting. Time hasn't been kind to the
> reference guide -- as language features were added to 2.x, not
> everything has been applied to the RefGuide, and users will probably
> have been forced to read a mixture of the RefGuide and various PEPs.
or as
Guido van Rossum wrote:
> Agreed. Is it too late to also attempt to bring Doc/ref/*.tex
> completely up to date and remove confusing language from it? Ideally
> that's the authoritative Language Reference -- admittedly it's been
> horribly out of date but needn't stay so forever.
it's perfectly p
Tim Peters wrote:
> > (Or are the two goals -- completeness and readability --
> > incompossible, unable to be met at the same time by one document?)
>
> No, but it's not easy, and it's not necessarily succinct. For an
> existence proof, see Guy Steele's "Common Lisp the Language". I
> don't th
Terry Reedy wrote:
> >> which reminds me of the following little absurdity gem from the language
> >> reference:
>
> > I am not sure of what you see as absurdity,
>
> Perhaps I do. Were you referring to what I wrote in the last paragraph of
> my response to Guido?
I don't know; I've lost track o
for some reason, the language reference uses the term "string con-
version" for the backtick form of "repr":
http://docs.python.org/ref/string-conversions.html
any suggestions for a better term ? should backticks be deprecated,
and documented in terms of repr (rather than the other way aroun
one last one for tonight; the operator precedence summary says that
"in" and "not in" has lower precedence than "is" and "is not", which
has lower precedence than "<, <=, >, >=, <>, !=, ==":
http://docs.python.org/ref/summary.html
but the comparisions chapter
http://docs.python.org/ref/c
Martin v. Löwis wrote:
> Ok. I think I would use base64, of possibly compressed content. It's
> more compact than your representation, as it only uses 1.3 characters
> per byte, instead of the up-to-four bytes that the img2py uses.
only if you're shipping your code as PY files. in PYC format (Z
Guido van Rossum wrote:
> They're all the same priority.
yet another description that is obvious only if you already know what
it says, in other words:
Operators in the same box have the same precedence. /.../
Operators in the same box group left to right (except for com-
parisons, i
Tim Peters wrote:
SF #1479181: split open() and file() from being aliases for each other.
>
>>> Umm ... why?
>
> [/F]
>> so that introspection tools can support GvR's pronouncement that "open"
>> should be used to open files, and "file" should be used as a type
>> representing
>> standard (c
Noam Raphael wrote:
> You can find the implementation at
> http://wiki.python.org/moin/AlternativePathModule?action=raw
> (By the way, is there some "code wiki" available? It can simply be a
> public svn repository. I think it will be useful for those things.)
pastebin is quite popular:
http
Heiko Wundram wrote:
>> Personally, I'm +1, but wonder if it would be enough to support '--help'
>> and '--version'. We then could cut out the "best guess" code and the code
>> to enable --opt=value.
>
> The code for the above functionality is about 10-12 lines of C of the whole
> patch.
>
> If th
fwiw, I just tested
http://pyref.infogami.com/with
on a live audience, and most people seemed to grok the "context
guard" concept quite quickly.
note sure about the "context entry value" term, though. anyone
has a better idea ?
___
Python-Dev
301 - 400 of 732 matches
Mail list logo
