also for
Python 3.0? If the former, as I mentioned before, that would be fine
with me. If the latter too, then I won't waste my time following up on
the thread or writing a PEP.
-Barry
signature.asc
Description: This is a digitally signed message part
__
On Mon, 2006-03-20 at 19:27 +1000, Nick Coghlan wrote:
> +1 on the separate mailing list (and PEP numbers).
I'm neutral on whether a new mailing list should be added, but +1 on
separate PEP numbers.
> If Barry (or another mailing list admin) is feeling energetic, some
> branch-s
00, which is too chaotic right now. See my new thread
> titled "Python 3000 Process".
Fair enough.
-Barry
signature.asc
Description: This is a digitally signed message part
___
Python-Dev mailing list
Python-Dev@python.org
http://
sprint time. Are you trying to make me shed
> a manly tear, Barry?!? =)
> So it isn't that PEP 352 is unnecessary since there is nothing here
> about deprecating string execptions and making built-in exceptions
> new-style. You just want to change the renaming of the exceptions.
On Sun, 2006-03-19 at 13:49 +1200, Greg Ewing wrote:
> Barry Warsaw wrote:
>
> > Exception
> > +- KeyboardInterrupt
> > +- GeneratorExit
> > +- SystemExit
> > +- StopIteration
> > +- Error
> > | +- ImportError
> > | +- (etc.)
> > |
&g
nce the term used for the general concept of something
that is raised and caught is "exception" and since all the raise-able
objects live in a module called "exceptions", it is confusing that
"except Exception" will not catch all exceptions.
-Barry
signature.a
o add an
alias called Error for StandardError. Then, users can begin to do the
sensible thing (as above).
-Barry
signature.asc
Description: This is a digitally signed message part
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.
errors, so "except Exception" should catch
them but "except Error" should not. This does speak to a generic
ControlFlow (but not ControlFlowError) base class.
-Barry
signature.asc
Description: This is a digitally signed message part
___
aise some good
points ;) and I'd rather carry the discussion forward on the soon to be
announced python-3000 mailing list.
-Barry
signature.asc
Description: This is a digitally signed message part
___
Python-Dev mailing list
Python-Dev@python.
On Mon, 2006-03-20 at 13:30 -0500, Terry Reedy wrote:
> "Guido van Rossum" <[EMAIL PROTECTED]> wrote in message
> >Barry, if you could create that mailing list, please?
>
> And please mirror it on gmane the same way as this list is.
Subscription requests have bee
On Mon, 2006-03-20 at 20:06 -0800, Guido van Rossum wrote:
> There's also a list for Python-3000-related checkins. Don't subscribe
> to that one yet, it's very boring and uninteresting. Also, Barry
> hasn't done the svn magic yet. :-)
We're having a small pro
I believe I've figured out the magic to split checkin messages so that
python/branches/p3yk goes to python-3000-checkins and everything else
goes to python-checkins. Let me know if you notice any problems, and
feel free to subscribe to whichever list(s) you're interested i
Try to enjoy the improvements without gilding the lily.
Let's embrace C and continue to make life easier for the C coder. You
can't argue that going through all the rigamarole of the iterator API
would be faster than PySet_Next(), and it certainly won't be more
readable or easier to d
On Tue, 2006-03-21 at 21:31 -0500, Raymond Hettinger wrote:
> [Barry]
> > Is it your intent to push for more use of the abstract API instead of
> > the concrete APIs for all of Python's C data structures? Current API
> > aside, are you advocating this approach
Python code, that knowledge is kept intact and there is no confusion
> > between
> > PyNumber_InPlaceAdd(s,t) vs PyObject_CallMethod(s, "update", "(O)", t).
>
> Of course, that should have been s|=t and PyNumber_InPlaceOr().
Heh, my point exactly. Y
ument them, teach people when not
to use them, and teach them how to use them correctly when they /are/
the right thing to use. I don't want to be babied into using
inappropriate and cumbersome APIs which, yes, can be a source of their
own subtle bugs.
-Barry
signature.asc
De
even that. These /are/ valid use
cases.
-Barry
signature.asc
Description: This is a digitally signed message part
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/m
On Sun, 2006-03-26 at 13:24 -0500, Raymond Hettinger wrote:
> We have a perfectly good way to iterate with PyIter_Next(). It may take a
> couple of extra lines, but it is easy to get correct and has no surprises.
> It
> seems that the only issue is that Barry says that he refuse
On Sun, 2006-03-26 at 21:50 +0200, "Martin v. Löwis" wrote:
> I don't know what specific application Barry has in mind, but I'm
> sure he can get it right (although it might be an interesting experiment
> to test that theory :-) In general, I would expect that people
t_Clear().
>
> This is plain evidence that something is wrong with your approach. While
> possibly necessary in your environment, the rest of mankind should not have
> to
> stomach this kind of API clutter.
Please, that's a bit extreme. I haven't heard anybody screa
On Mon, 2006-03-27 at 10:20 -0500, Raymond Hettinger wrote:
> Why don't we expose _PySet_Next() for Barry and leave it out of the public
> API
> for everyone else.
Just so I understand exactly what you mean by "leave it out of the
public API", let me ask: are you
On Mon, 2006-03-27 at 23:21 +0200, "Martin v. Löwis" wrote:
> Raymond Hettinger wrote:
> > Why don't we expose _PySet_Next() for Barry and leave it out of the public
> > API
> > for everyone else.
>
> That is stupid. If Barry wants a "private&q
onable.
>
> +1 from me.
>
> Anyone disagree?
Not me!
-Barry
signature.asc
Description: This is a digitally signed message part
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe
releases if he wanted to -- I do
that with the email package, and while it's a bit of a PITA, it's
doable.
Either sqlite or sqlitedb are fine names.
-Barry
signature.asc
Description: This is a digitally signed message part
___
Python-Dev mai
not the chair)
is examining the alternatives and trying to put up some live demos for
people to check out. Getting the data out of SourceForge has been the
sticky issue though, and last I recall, we were waiting for some
response from them about export bugs we'd encountered.
-Barry
signat
On Tue, 2006-03-28 at 17:28 +1200, Greg Ewing wrote:
> Barry Warsaw wrote:
> > My PySet_Clear() raises a SystemError
> > and returns -1 when the object is a frozen set.
>
> Isn't SystemError a bit drastic? TypeError would be
> sufficient here, surely.
Possi
rectly addresses
your concerns though, since they seem mostly centered around the safety
(or lack thereof) of PySet_Next().
-Barry
signature.asc
Description: This is a digitally signed message part
___
Python-Dev mailing list
Python-Dev@python.org
http://m
> For many applications the size of your sets is O(1) too. (Often with
> quite a small implicit constant, too.)
My sentiments exactly Gareth. Thanks for putting it so much more
eloquently than I have. :)
-Barry
signature.asc
Description: This is a digitally signed message part
__
ee didn't,
> either. Does it need a BDFL pronouncement? I'd say yes.
If Guido even cares ;), but if not, RM pronouncement is good enough for
me.
-Barry
signature.asc
Description: This is a digitally signed message part
___
Python-D
about which to add, then it might
make better sense to wait and not add either for Python 2.5.
-Barry
signature.asc
Description: This is a digitally signed message part
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/l
uments took multiple
> lines to list. Both of these are routine occurrences for my class use cases.
We have a couple of instances where we use multiple decorators, and even
a case where one of them takes an argument. It's not too bad. I agree
with your comments about class
On Wed, 2006-03-29 at 09:35 +0200, Gerhard Häring wrote:
> In particular, I would then synchronize changes that have proven stable
> in the standalone release to the Python core sqlite module. I think this
> is how Barry does it with the email module, too.
I do things a little differ
atabase.sqlite' rather than 'db.sqlite'.
+1 on 'database' as the top-level package name.
-Barry
signature.asc
Description: This is a digitally signed message part
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.pytho
hat
there are differing opinions.
-Barry
signature.asc
Description: This is a digitally signed message part
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/o
On Tue, 2006-03-28 at 22:20 -0800, Raymond Hettinger wrote:
> Barry, go ahead with PySet_Clear().
Cool thanks. I think we've also compromised on _PySet_Next(), correct?
I'll follow up on PySet_Update() in a moment.
-Barry
signature.asc
Description: This is a digitally signed
single argument).
So why not just go ahead and do that now? If you know that's what you
want eventually, why wait? From my perspective, adding a NULL at the
end of the argument list wouldn't be that big of a deal.
-Barry
signature.asc
Description: This is a digi
On Wed, 2006-03-29 at 19:34 -0500, Barry Warsaw wrote:
> On Wed, 2006-03-29 at 16:29 -0500, Raymond Hettinger wrote:
>
> > The story is different for PySet_Update(). Defining it now could get in
> > the way
> > of possible future development for the module (the functio
y're
very cool folks. I'll leave it up to Brett to decide though, since he's
chair of the infrastructure committee. I'm happy to ask them though.
-Barry
signature.asc
Description: This is a digitally signed message part
_
ousands of Python developers out there
> that are used to working with Trac.
FWIW, Atlassian has made the same generous offer for Mailman, and I am
going to accept it (assuming we can ever get the freakin' data out of
SF).
-Barry
signature.asc
Description:
On Thu, 2006-03-30 at 10:39 +0200, Georg Brandl wrote:
> Perhaps that Jira is commercial, so it is out of the question for most
> open-source Python applications.
Sorry, I don't follow. Why is a commercial product out of the question
for Python?
-Barry
signature.asc
Description
bug tracker, and that
> this may be the reason that Jira isn't used widely by Python programmers.
Gotcha, sorry I misunderstood. BTW, Atlassian does have a program to
provide free licenses to open source projects. Here's their FAQ item on
it:
http://www.atlassian.com/about/li
s that mean you won't add a vararg version? Or you won't add the
function at all? I'm all for making things fast, but I just don't
believe that in general that should be the primary driver for how you
want people to /use/ your objects.
-Barry
signature.asc
Description: This is
e on this thread. It has consumed far too much development time already.
> Please write a one-line macro for yourself and leave this alone so I can
> continue the development efforts at a thoughtful pace.
As per your comment in patch 1458476, I will add _PySet_Update() and
consider this th
wsgroup list. Was this intentional on the part of the mail list
> maintainers? (I certainly hope not!) Or is it a repairable glitch
> somewhere between the list and gmane?
No idea, but the ng's do appear to be gone. Definitely not intentional
on our part!
-Barry
signature.asc
Tim Peters wrote:
>
> While we're at it, looks like all the 2.4 buildbots are failing
> test_email today.
> ___
>
Anthony backported the patch that should fix this, so it should be
showing up in 2.4 bui
translation context, find the
string's translation, then does the substitutions.
So this is one difficult sticking point with the idea.
-Barry
signature.asc
Description: This is a digitally signed message part
___
Python-Dev mailing list
Pytho
ards).
That's essentially what I do in Mailman, although I use
def _(s): return s
same-difference-ly y'rs,
-Barry
signature.asc
Description: This is a digitally signed message part
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.pyt
ers, the order may change in some
translations.
-Barry
signature.asc
Description: This is a digitally signed message part
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail
On Sat, 2006-04-08 at 14:47 -0700, Brett Cannon wrote:
> - email
This has an standalone release, but development and bug reports should
all happen in the Python project.
-Barry
signature.asc
Description: This is a digitally signed message p
grated with external tools. Heck, I wouldn't even
mind a big ol' "if sys.hexversion" at the top of them for backward
compatibility for a while if necessary.
-Barry
signature.asc
Description: This is a digitally signed message part
___
he Python 2.5, release, but when it *is* available
> you'll just "python -m easy_install --upgrade setuptools" to get it. :)
Cool. Sticking with the metaphor, where's the 'hatch' command and what
would it do? :)
-Barry
signature.asc
Description: This is a dig
ing on
there that I wouldn't want emulated.
-Barry
signature.asc
Description: This is a digitally signed message part
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.py
beta released, feedback gathered, bugs
accepted, patches accepted, re-released, maintained, backward
compatibility supported forever, etc. etc. Oh wait, yes definitely
easier to rewrite .
way-off-topic-now-ly y'rs,
-Barry
signature.asc
Description: This is a digitally signed message part
___
of backward compatibility crap. (It's always more fun
to remove code than add new code :).
At some point you have to move on. Python 2.1 and 2.2 are getting
increasingly difficult to support, and I've found less and less call for
it from my users. OTOH, Python 2.3 is still very popular,
purelib
switches, which was pretty difficult (IIRC) to figure out.
Again, maybe there's an easy way to do this with modern distutils, but I
just want to make sure this is a use case that's on the radar.
-Barry
signature.asc
Description: This is a digitally signed message part
depends on.
Question out of total ignorance: say I get a 3rd party package that has
a standard distutils setup.py but knows nothing of setuptools. Say I
install my own copy of setuptools (or have Python 2.5). Can that 3rd
party package still be installed "th
th Park watching time based on some complex algorithm
involving the email he receives. He's explained it to me several times,
but I'm too dumb to get it.
-Barry
signature.asc
Description: This is a digitally signed message part
___
Python-Dev ma
his list this is all there is to it:
with EXPR:
block
with needs a context. If the EXPR object has a __context__ method
it is a factory that will make a suitable context for the EXPR object
otherwise EXPR is the context.
that context must have __enter__ and __exit__ methods to operat
mport things having to be more cautious about
cleansing their __import__() arguments now.
I'd be -1 but the remote possibility of you being burned at the stake by
your fellow Googlers makes me -0 :).
-Barry
signature.asc
Description: This is a digitally signed message part
___
e right when you say that if the rule had already been relaxed and
you were now proposing to tighten the rules, we probably get just as
many complaints.
alternative-universe-ly y'rs,
-Barry
signature.asc
Description: This is a digitally signed message part
faster. It depends on your application. The number
of FDs and the fd values affect the point that kqueue wins over select.
For a few FDs with low values select was always faster in my apps.
Barry
___
Python-Dev mailing list
Python-Dev@python.org
d in Py3K those plans might finally come to fruition. :)
BTW, A while back I think I posted a "py3k" cc-mode style for you
X/Emacs hackers out there. It's based on the standard "python" style
but changes c-basic-offset and indent-tabs-mode. Let me know if you
can't
ndar that has the various Python dev related dates in it?
Great idea!
- -Barry
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2.2 (GNU/Linux)
iQCVAwUBRImofnEjvBPtnXfVAQL61wP/XLobIymHE5WsVsS+6Rrcy3mHPgnPgjlR
CYLLD0/71Qn5RXKTEvJ1ZWxLgzRSKeT2gzrp1T+bvcblksZcXBGYLXC2y5d0xo2W
WLRnFLeVUmA0X+t573EmvOoA
or versions of email. Two of them pull from branches in the
Python repo while one (currently) pulls from the trunk. Yes, it's a
PITA, but I could reduce the amount of work by deciding on a different
mix of version compatibility.
I don't know if that will work for the other PEP 360
e same thing. The
PITA is that I have to build the docs in Python's svn and then copy
them into the sandbox for the standalone distro. This isn't to bad
when it's just one package, but if we adopt this approach more
generally, we may want to establish some guidelines, which of course
biness. That's okay, I'll only hold it against you until the end
of time.
oh-heck-let-the-psf-buy-a-round-for-the-house-ly y'rs,
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/pyth
x = 1
def bar():
x = 2
def baz():
x as if in foo = 3
x as if in global += 1
(Personally, I've never really needed this much, but if you have to
have it, be explicit! :)
- -Barry
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.3 (Dar
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Jul 5, 2006, at 9:39 AM, [EMAIL PROTECTED] wrote:
>
> Barry> Clearly we need the "as if in" operator:
>
> Why not be more direct?
Sure, why not? :)
Then we can reserve the "as if" operator for those things
explain that all can take iterables
I consider this a bug in 2.4, not a new feature, because without it, it
makes more work in porting applications.
Thoughts?
I'm willing to Just Fix It, but if someone wants to see a patch first,
I'll be happy to generate it and post it to SF.
-Barry
sure it's vastly superior.
I'm concerned with the API. I don't agree that dropping union_update()
is necessarily an improvement, but I guess I had my chance when the PEP
was being debated, so I'll drop it.
I do think you owe it t
ing "endswith", as in the
string method of similar name. ;)
Slightly silly alternative: __within__ and __without__
Otherwise, +0 on __enter__ and __exit__.
-Barry
signature.asc
Description: This is a digitally signed message part
___
Python
hey're needed. Also, I don't think they're
really much of a burden on newbies because mostly, they just don't
encounter them or need to know about them.
-Barry
signature.asc
Description: This is a digitally signed message part
___
P
o you
(or you can just take it).
We fixed it about 10 minutes ago and have only done minimal testing so
far, but I'm going to upload it anyway.
-Barry
signature.asc
Description: This is a digitally signed message part
___
Python-Dev mailing list
Py
alues. I'd love to see cm's for those constructs in the stdlib.
-Barry
signature.asc
Description: This is a digitally signed message part
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
U
t string literals need to change in any
way. Dedentation should be handled (is handled?!) in the stdlib.
-Barry
signature.asc
Description: This is a digitally signed message part
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python
On Mon, 2005-07-25 at 16:37, Edward C. Jones wrote:
> Is there a C API for the built-in type set? if not, why not?
Sadly, no. Because no one's written it yet...?
-Barry
signature.asc
Description: This is a digitally signed message part
__
parate repos).
> As the repository format, fsfs should be used (requires Subversion 1.1).
> fsfs has the advantage of being more backup-friendly, as it allows to
> backup a repository incrementally, without requiring to run any dump
> commands.
Definitely +1
rust (I think I've heard that they have even modified
> their SSH server to be stricter).
James has a very interesting idea for mitigating this. Presumably
, we'll have backups of everything. I'll feel better when we have
coverage from maybe 6 admins spanning as many timezone
anged.
>
> Then at least you know how much you need to examine instead of having
> to treat the entire repository as possibly contaminated.
Would it buy us any additional piece of mind to checksum the transaction
files as they're committed and store those checksums outside the
e security then is in the passwords, so we have to make
sure they're generated securely.
> We should have enough man powers to come up with some secure solution
> here :).
Volunteers (i.e. those with actual free time to give on implementing any
solution) are definitely welcome.
-Ba
-side tagging. Those are done with urls and in those cases, long
urls can suck. But we may not do a ton of that with the Python project,
and besides it might not be important enough to split the directories.
-Barry
signature.asc
Description: This is a digitally signed message part
_
On Thu, 2005-07-28 at 22:59, Tim Peters wrote:
> Yup, me too -- between the two of us, we don't have enough fingers to
> count how many trunks, branches, and tags of ZODB and Zope I have to
> fiddle with.
I have a small inkling of your pain.
> They're all still copy, paste, tail-edit for me, and
On Fri, 2005-07-29 at 01:00, "Martin v. Löwis" wrote:
> Barry Warsaw wrote:
> > We won't use plain text, but we may (or, we currently do) use basic auth
> > over ssl. The security then is in the passwords, so we have to make
> > sure they're generated secu
ile changes, we were compromised (there are,
> of course, a few files that do change regularly).
> Of course, we also need regular backups of the entire data
> so we can restore them if they got compromised.
+1 to all that.
-Barry
hutdown
> latest (as tmp is cleaned on reboot).
I don't think that's true on all Linuxes though (or even all *nixes).
-Barry
signature.asc
Description: This is a digitally signed message part
___
Python-Dev mailing list
Python-Dev@pyt
ou could give different access to peps and to sandbox.
> Perhaps there isn't even a need for tags/branches on PEPs?
Probably so.
-Barry
signature.asc
Description: This is a digitally signed message part
___
Python-Dev mailing list
Python-Dev@p
for
> this process; the older machine has 512MB).
That matches my experience w/ the fsfs backend. If we do the conversion
on one of the new python.org boxes, I expect it to go pretty quickly.
-Barry
signature.asc
Description: This is a digitally signed message part
_
ot Python and they're not open source, so perhaps it's
legitimate to dismiss them because of that. But they are also
definitely cool. At the Atlassian folks are very cool too, and fans of
FOSS.
-Barry
signature.asc
Description: This is a digitally signed message part
__
atters if you use urls. I working directories, I think
everything gets tracked correctly. I could be wrong about that though.
-Barry
signature.asc
Description: This is a digitally signed message part
___
Python-Dev mailing list
Python-Dev@python.org
http:
ed more volunteers, well the community has
always stepped up before and I'm sure it will when we come asking again.
Actually, it's a good idea to /always/ be soliciting for help. People
get burned out and busy and I'd love to have a bullpen of volunteers
that gets constantly r
On Fri, 2005-07-29 at 18:12, Leif Hedstrom wrote:
> Barry Warsaw wrote:
>
> >Public/private keys would be better, and if anybody knows how to set up
> >a Subversion server to use these without having to create accounts for
> >everyone, I think we (the pythong.org admi
ther admins.
We'd also have to teach the current crop of developers how to use the
client tools effectively. I think it's fairly simple to teach a CVS
user how to use Subversion, but have no idea if translating CVS
experience to Perforc
nd for Tim's sake I won't even complain about how some
operating systems appear to perform much worse than others :).
The smaller you can keep your working copies, the better.
-Barry
signature.asc
Description: This is a digitally signed message part
_
bug report:
https://sourceforge.net/tracker/index.php?func=detail&aid=900092&group_id=5470&atid=105470
which fixes a long standing hotshot bug. Any objections?
-Barry
signature.asc
Description: This is a digitally signed message part
___
Pyt
o switch to svn now, while
continuing to experiment and follow the better scm systems for the
future.
-Barry
signature.asc
Description: This is a digitally signed message part
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/li
want to do that
ourselves anyway. There may be occasional infrastructural work that
needs to happen (e.g. we still owe Martin a login for tunneling), but
those tasks seem to me to be better handled either by volunteers or by
short-term paid piece work.
-Barry
signature.asc
Description: This is
name id.
Same here.
> The sys module seems like a natural
> place to put id(), since it is exposing something about the
> implementation of Python rather than something about the language; the
> language offers the is operator to check ids.
+1
-Barry
signature.asc
Description:
posted to python-dev, you might think about adding Python to
the list of languages "in which [...] the project [is] written" on the
registration form. Currently, the only choices are C/C++, Java, and
php.
-Barry
signature.asc
Description: Thi
tin v. Loewis".
I'm confused again; are you saying that we should have a host named
pythondev.python.org? I'm not sure that's necessary.
-Barry
signature.asc
Description: This is a digitally signed message part
___
Python-Dev m
e needed and to support different certs for svn.python.org and
(eventually) www.python.org.
-Barry
signature.asc
Description: This is a digitally signed message part
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mai
2601 - 2700 of 2826 matches
Mail list logo
