Hello,
just felt a little bored and tried to review a few (no-brainer) patches.
Here are the results:
* Patch #1051395
Minor fix in Lib/locale.py: Docs say that function _parse_localename
returns a tuple; but for one codepath it returns a list.
Patch fixes this by adding tuple(), recomme
Hello,
this time working up some of the patches with beards:
- #751943
Adds the display of the line number to cgitb stack traces even when
the source code is not available to cgitb. This makes sense in the
case that the source is lying around somewhere else. However, the
original patch g
Reinhold Birkenfeld wrote:
> Hello,
>
> this time working up some of the patches with beards:
No one listening? I'm sorry when patch reviews are not welcome in
python-devel; in this case I'll post individual comments to the patch
Aahz wrote:
> On Wed, Feb 23, 2005, Reinhold Birkenfeld wrote:
>> Reinhold Birkenfeld wrote:
>>>
>>> this time working up some of the patches with beards:
>>
>> No one listening? I'm sorry when patch reviews are not welcome in
>> python-devel;
While rummaging in the old patches, I found this:
"""
The result of the PyCore sprint of me and Brett: the CALL_ATTR opcode
(LOAD_ATTR and CALL_FUNCTION combined) that skips the PyMethod creation
and destruction for classic classes (but not newstyle classes, yet.)
The code is somewhat rough yet,
Hello,
still in 2004, this comment was added to old bugs with groups Python2.*:
"""
Please, could you verify if this problem persists in Python
2.3.4
or 2.4?
If yes, in which version? Can you provide a test case?
If the problem is solved, from which version?
Note that if you fail to answer in
Nick Coghlan wrote:
> Raymond Hettinger wrote:
>> Decorators like this should preserve information about the underlying
>> function:
>>
>>
>>>def deprecated(func):
>>>"""This is a decorator which can be used to mark functions
>>>as deprecated. It will result in a warning being
Guido van Rossum wrote:
> See my blog: http://www.artima.com/forums/flat.jsp?forum=106&thread=98196
>
> Do we even need a PEP or is there a volunteer who'll add any() and all() for
> me?
There is an interesting proposal in the forum:
"""
He proposes that
[x in list if x > 0]
(which is current
Martin v. Löwis wrote:
> Rodrigo Dias Arruda Senra wrote:
>> I propose a small change in webbrowse.py module.
>
> I think I'm generally in favour of such a change. However:
>
> - please don't post patches to python-dev, unless you *want*
>them to be ignored. Typically, nobody will pick up pat
Ka-Ping Yee wrote:
> It dawned on me that you could use this idea to make the whole
> filter/lambda experience vastly more pleasant. I whipped up a quick
> implementation:
>
> >>> from placeholder import _
> >>> numbers = [5, 9, 56, 34, 1, 24, 37, 89]
> >>> filter(_ < 30, numbers)
>
Ka-Ping Yee wrote:
> On Wed, 23 Mar 2005, Reinhold Birkenfeld wrote:
>> What does you implementation do for this:
>>
>> >>> somevar = False
>> >>> filter(_ and False, numbers)
>
> It fails. (For the same reason that __len__ doesn't work
Rodrigo Dias Arruda Senra wrote:
> | > On Thu, Mar 24, 2005 at 11:36:41AM -0300, Rodrigo Dias Arruda Senra
> wrote:
> | > > Edit libwebbrowser.tex as you see fit, then send it to me
> | > > and I'll TeXify it back to you.
> | >
> | >Uploaded to http://python.org/sf/754022 . I am not a n
Guido van Rossum wrote:
>> What was your opinion on "where" as a lambda replacement? i.e.
>>
>> foo = bar(callback1, callback2) where:
>> def callback1(x):
>> print "hello, "
>> def callback2(x):
>> print "world!"
>
> I don't recall seeing this proposed, but I might h
Nick Coghlan wrote:
> Interestingly, with this approach, "for dummy in my_resource()" would still
> wrap
> the block of code in the entrance/exit code (because my_resource *is* a
> generator), but it wouldn't get the try/finally semantics.
>
> An alternative would be to replace the 'yield None
Guido van Rossum wrote:
> [Greg Ewing]
>> I like the general shape of this, but I have one or two
>> reservations about the details.
>
> That summarizes the feedback so far pretty well. I think we're on to
> something. And I'm not too proud to say that Ruby has led the way here
> to some extent (e
Nick Coghlan wrote:
> Guido van Rossum wrote:
> [snip]
>> - I think there's a better word than Flow, but I'll keep using it
>> until we find something better.
>
> How about simply reusing Iteration (ala StopIteration)?
>
>Pass in 'ContinueIteration' for 'continue'
>Pass in 'BreakIterati
Guido van Rossum wrote:
>> Another possibility just occurred to me. How about "using"?
>
> Blah. I'm beginning to like block just fine. With using, the choice of
> word for the generator name becomes iffy IMO; and it almost sounds
> like it's a simple renaming: "using X as Y" could mean "Y = X".
: $Revision: $
Last-Modified: $Date: $
Author: Reinhold Birkenfeld <[EMAIL PROTECTED]>
Status: Draft
Type: Standards Track
Content-Type: text/plain
Created: 04-May-2005
Post-History:
Abstract
This PEP proposes a change in the syntax and semantics of try
statements to allow combined try-
Paul Moore wrote:
> On 5/4/05, Alex Martelli <[EMAIL PROTECTED]> wrote:
>>
>> On May 4, 2005, at 01:57, Paul Moore wrote:
>> >
>> > I can't think of a reasonable condition which wouldn't involve reading
>> > the file - which either involves an inner loop (and we already can't
>> > break out of two
Adam Souzis wrote:
> I'm a bit surpised that no one has yet [1] suggested "begin" as a
> keyword instead "block" as it seems to express the intent of blocks
> and is concise and readable. For example, here are the examples in
> PEP 340 rewritten using "begin":
>
> begin locking():
>...
I don
Rodrigo Dias Arruda Senra wrote:
> [ Guido ]:
> > 1. Decide on a keyword to use, if any.
>
> Shouldn't be the other way around ?
> Decide to use *no* keyword, if that could be avoided.
[...]
> Following the PEP and this thread, it seems to me that __no keyword__
> is less preferable than _
Noam Raphael wrote:
> On 5/4/05, Reinhold Birkenfeld <[EMAIL PROTECTED]> wrote:
>>
>> There is one problem with using no keyword: You cannot use arbitrary
>> expressions
>> in the new statement. Consider:
>>
>> resource = opening("file.txt
Tim Peters wrote:
> [Guido]
>> I'm +1 on accepting this now -- anybody against?
>
> I'm curious to know if you (Guido) remember why you removed this
> feature in Python 0.9.6? From the HISTORY file:
>
> """
> New features in 0.9.6:
> - stricter try stmt syntax: cannot mix except and finally clau
Ka-Ping Yee wrote:
> Reinhold Birkenfeld wrote:
>> Well, with it you could create suites with _any_ introducing
>> identifier. Consider:
>>
>> with:
>> (...)
>>
>> synchronized:
>> (...)
>>
>> try:
>> (...)
>>
Shane Hathaway wrote:
> For each block statement, it is necessary to create a *new* iterator,
Right.
> since iterators that have stopped are required to stay stopped. So at a
> minimum, used-defined statements will need to call something, and thus
> will have parentheses. The parentheses might
Tim Peters wrote:
> [Reinhold Birkenfeld]
>> ...
>> I think the behaviour of the "else" clause is much harder to guess,
>> mainly when used with the looping constructs.
>
> No, that's obvious .
OK, I'm persuaded. Well you wield the Force, mas
Aahz wrote:
> On Wed, May 04, 2005, Paul Moore wrote:
>>
>> Yes, that'd do. I can't say I think it would be common, but it's a
>> valid case. And the workaround is the usual messy flag variable:
>>
>> for name in filenames:
>> found = False
>> opening(name) as f:
>> if f.read(2) ==
Guido van Rossum wrote:
> [François Pinard]
>> It happens once in a while that I want to comment out the except clauses
>> of a try statement, when I want the traceback of the inner raising, for
>> debugging purposes. Syntax forces me to also comment the `try:' line,
>> and indent out the lines fo
Hello,
would anybody mind if I was given permissions on the tracker and CVS, for
fixing small
things like bug #1202475. I feel that I can help you others out a bit with this
and
I promise I won't change the interpreter to accept braces...
Reinhold
--
Mail address is perfectly valid!
Raymond Hettinger wrote:
> [Reinhold Birkenfeld]
>> would anybody mind if I was given permissions on the tracker and CVS,
> for
>> fixing small
>> things like bug #1202475. I feel that I can help you others out a bit
> with
>> this and
>> I promise I won&#x
Raymond Hettinger wrote:
>> I've seen some systems that solve this problem by allowing users to
> "vote"
>> for favorite bugs... then you can tell the "important" bugs because
> they
>> are more likely to have lots of votes. As I see it, Facundo is using a
>> variant of that system. He is asking wh
While looking at bug #779191, I saw that sys.path's first element
is '' in interactive sessions, but the current dir otherwise. Is this
intentional?
Reinhold
--
Mail address is perfectly valid!
___
Python-Dev mailing list
Python-Dev@python.org
http://
Hello,
I am currently having some thoughts about the standard library, with regard
to Python 2.5 and 3.0. Since I don't want to withhold them from you, here
are they ;)
- Flat namespace: Should we tend to a more hierarchic library (e.g.
inet.url, inet.http, inet.nntp)? This would increase clari
Skip Montanaro wrote:
> Tim> On 6/6/05, Reinhold Birkenfeld <[EMAIL PROTECTED]> wrote:
>
> >> - Flat namespace: Should we tend to a more hierarchic library (e.g.
> >> inet.url, inet.http, inet.nntp)? This would increase clarity when
> >> s
Fernando Perez wrote:
> Skip Montanaro wrote:
>
>> I wouldn't mind a stdlib that defined a set of top-level packages (some of
>> which might be wholly unpopulated by modules in the standard distribution)
>> It might, for example, define a gui package and gui.Tkinter and gui._tkinter
>> modules, le
Kay Schluehr wrote:
> Reduction provides often the advantage to make expressions/statements
> scriptable what they are not in Python. Python is strong in scripting
> classes/objects ( a big plus of the language ) but you can't simply use
> the language to prove that
>
> lambda
Kay Schluehr wrote:
> Reinhold Birkenfeld wrote:
>
>>>
>>>lambda x,y: x+y*y
>>>lambda x,y: y**2+x
>>>
>>> are essentialy the same functions with different implementations [1].
>>
>>
>> Exce
Hi,
while bugs and patches are sometimes tricky to close, RFE can be very easy
to decide whether to implement in the first place. So what about working a
bit on this front? Here are several RFE reviewed, perhaps some can be
closed ("should" is always from submitter's point of view):
1193128:
str.
Phillip J. Eby wrote:
> At 06:57 PM 6/26/2005 +0200, Reinhold Birkenfeld wrote:
>>1226256:
>>The "path" module by Jason Orendorff should be in the standard library.
>>http://www.jorendorff.com/articles/python/path/
>>Review: the module is great and seems
Tim Peters wrote:
> [EMAIL PROTECTED]
>> Update of /cvsroot/python/python/dist/src/Lib
>> In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv4891/Lib
>>
>> Modified Files:
>>Cookie.py
>> Log Message:
>> bug [ 1108948 ] Cookie.py produces invalid code
[...]
> I assume this accounts for
Michael Hoffman wrote:
> On Sun, 26 Jun 2005, Phillip J. Eby wrote:
>
>> At 08:19 PM 6/26/2005 +0100, Michael Hoffman wrote:
>>> On Sun, 26 Jun 2005, Phillip J. Eby wrote:
>>>
* drop getcwd(); it makes no sense on a path instance
>>>
>>> Personally I use path.getcwd() as a class method all th
Phillip J. Eby wrote:
> At 08:20 AM 6/27/2005 +0100, Michael Hoffman wrote:
>>os.getcwd() returns a string, but path.getcwd() returns a new path
>>object.
>
> In that case, I'd expect it to be 'path.fromcwd()' or 'path.cwd()'; i.e. a
> constructor classmethod by analogy with 'dict.fromkeys()' or
Michael Hoffman wrote:
> On Wed, 29 Jun 2005, Tony Meyer wrote:
>
>> Maybe this has already been answered somewhere (although I don't
>> recall seeing it, and it's not in the sourceforge tracker) but has
>> anyone asked Jason Orendorff what his opinion about this (including
>> the module in the st
Nick Coghlan wrote:
[...]
> If the right hand side of 'as' permitted the same forms as are going
> to be permitted for the 'as' clause in 'with' statements, then Ralf's
> situation could be handled via:
>
>def __init__(self as s, x as s.x, y as s.y, z as s.z):
> pass
>
> Essentially
Paul Moore wrote:
> On 7/6/05, Michael Chermside <[EMAIL PROTECTED]> wrote:
>> Paul Moore writes:
>> > I also like the fact that it offers a neat 1-word name for the
>> > generator decorator, "@context".
>>
>> Well, ok... does anyone *else* agree? I too saw this and thought "neat!
>> a simple one-
Hi,
I compiled a list of some possible new context managers that could be
added to the stdlib. Introducing a new feature should IMO also show
usage of it in the distribution itself. That wasn't done with
decorators (a decorators module is compiled at the moment, if I'm right),
but with context man
Phillip J. Eby wrote:
> At 10:24 PM 7/8/2005 +0200, Reinhold Birkenfeld wrote:
>>with sys.trace
>
> Note that it's currently not possible to inspect the trace/profile hooks
> from Python code, only from C, so that might be, um, interesting to implement.
That w
Raymond Hettinger wrote:
>> > I compiled a list of some possible new context managers that could
> be
>> > added to the stdlib. Introducing a new feature should IMO also show
>> > usage of it in the distribution itself. That wasn't done with
>> > decorators (a decorators module is compiled at the m
Guido van Rossum wrote:
> On 7/5/05, Andrew Durdin <[EMAIL PROTECTED]> wrote:
>> I have written a patch that changes the way triple-quoted strings are
>> scanned so that leading whitespace is ignored in much the same way
>> that pep 257 handles it for docstrings. Largely this was for a
>> learning
Terry Reedy wrote:
> "Andrew Durdin" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
>> Very likely. But given the number of times that similar proposals have
>> been put forth in the past, it is reasonable to expect that they will
>> be brought up again in the future by others, if t
Hi,
would anyone care to comment about this patch of mine --
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1214889&group_id=5470
It makes file.encoding read-write and lets the write() and writelines() methods
obey it.
Reinhold
--
Mail address is perfectly valid!
__
M.-A. Lemburg wrote:
> Reinhold Birkenfeld wrote:
>> Hi,
>>
>> would anyone care to comment about this patch of mine --
>> https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1214889&group_id=5470
>>
>> It makes file.encoding read-writ
Hi,
to whom it may concern:
the Python package on PyPI is at version 2.3.2.
Reinhold
--
Mail address is perfectly valid!
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.py
Reinhold Birkenfeld wrote:
> Hi,
>
> while bugs and patches are sometimes tricky to close, RFE can be very easy
> to decide whether to implement in the first place. So what about working a
> bit on this front? Here are several RFE reviewed, perhaps some can be
> closed ("
[EMAIL PROTECTED] wrote:
> Update of /cvsroot/python/python/dist/src/Doc/lib
> In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv20654
>
> Modified Files:
> emailutil.tex
> Log Message:
> Note that usegmt is new in 2.4. Closes #1239681.
>
>
> Index: emailutil.tex
> ==
Ruslan Spivak wrote:
> Hello.
>
> I was reading source code for bltinmodule.c and found probably erroneus
> stuff in filter function. I'm newbie to python inners and don't know if
> attached code is worth for a patch submission.
>
> I would appreciate if someone could take a look at it and if it'
Reinhold Birkenfeld wrote:
> Ruslan Spivak wrote:
>> Hello.
>>
>> I was reading source code for bltinmodule.c and found probably erroneus
>> stuff in filter function. I'm newbie to python inners and don't know if
>> attached code is worth for a pat
Raymond Hettinger wrote:
> 2. There is a lesson to be taken from a story in the ACM risks forum
> where a massive phone outage was traced to a single line of C code that
> ran a "break" to get out of a nested if-statement. The interesting part
> is that this was known to be mission critical code
Guido van Rossum wrote:
> The main problem for a smooth Unicode transition remains I/O, in my
> opinion; I'd like to see a PEP describing a way to attach an encoding
> to text files, and a way to decide on a default encoding for stdin,
> stdout, stderr.
FWIW, I've already drafted a patch for the
Christian Robottom Reis wrote:
> In Launchpad (mainly because SQLObject is used) we end up with quite a
> few locals named id. Apart from the fact that naturally clobbering
> builtins is a bad idea, we get quite a few warnings when linting
> throughout the codebase. I've fixed these as I've found t
[EMAIL PROTECTED] wrote:
I'm not a native speaker, but...
> @@ -114,7 +114,7 @@
> programs, or to test functions during bottom-up program development.
> It is also a handy desk calculator.
>
> -Python allows writing very compact and readable programs. Programs
> +Python enables programs to wri
Hi,
after adding Oleg Broytmann's findnocoding.py to Tools/scripts, I wonder
whether the Tools directory is documented at all. There are many useful
scripts there which many people will not find if they are not listed
anywhere in the docs.
Just a thought.
Reinhold
--
Mail address is perfectly
Raymond Hettinger wrote:
>> Deprecation means your code will still work I hope every book that
>> documents "except:" also adds "but don't use this except under very
>> special circumstances".
>>
>> I think you're overreacting (again), Raymond. 3.0 will be much more
>> successful if we can introdu
A.B., Khalid wrote:
> Hello there,
>
>
> The release24-maint check-ins for today contained this typo:
>
> ===
> RCS file: /cvsroot/python/python/dist/src/Modules/operator.c,v
> retrieving revision 2.29
> retrieving revision 2.29.4.1
Tim Peters wrote:
> [EMAIL PROTECTED]
>> Update of /cvsroot/python/python/dist/src/Lib/test
>> In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv4822/Lib/test
>>
>> Modified Files:
>>test_bz2.py
>> Log Message:
>> Add list() around xreadlines()
>>
>>
>>
>> Index: test_bz2.py
>>
Bill Janssen wrote:
>> There are basically two ways for a system, such as a
>> Python function, to indicate 'I cannot give a normal response." One (1a)
>> is to give an inband signal that is like a normal response except that it
>> is not (str.find returing -1). A variation (1b) is to give an
A.B., Khalid wrote:
> #--- Python 2.5a0 from CVS -#
> # Result: passes
> $ /g/projs/py25/python/dist/src/MinGW/python testbz2.py
>
>
> #--- Python 2.4.1 from CVS -#
> # Result: fails
> $ /g/projs/py24/python/dist/src
Raymond Hettinger wrote:
> [Martin]
>> For another example, file.read() returns an empty string at EOF.
>
> When my turn comes for making 3.0 proposals, I'm going to recommend
> nixing the "empty string at EOF" API. That is a carry-over from C that
> made some sense before there were iterators.
A.B., Khalid wrote:
>>>#--- Python 2.4.1 from CVS -#
[test_bz2]
>>>RuntimeError: wrong sequence of bz2 library commands used
>>
>>I don't understand this. The sources for the bz2 modules are exactly equal
>>in both branches.
>
> I know. Even the tests are e
Bill Janssen wrote:
>> >(*) Regular Expressions
>>
>> This can be orthogonally added to the 're' module, and definitely should
>> not be part of the string method.
>
> Sounds right to me, and it *should* be orthogonally added to the 're'
> module coincidentally simultaneously with the change
Greg Ewing wrote:
> Charles Cazabon wrote:
>
>> Perhaps py3k could have a py2compat module. Importing it could have the
>> effect of (for instance) putting compile, id, and intern into the global
>> namespace, making print an alias for writeln,
>
> There's no way importing a module could add som
,
>
> [Greg Ewing]
>> > There's no way importing a module could add something that
>> > works like the old print statement, unless some serious
>> > magic is going on...
>
> [Reinhold Birkenfeld]
>> You'd have to enclose print arguments in paren
Raymond Hettinger wrote:
>> Do we really need writef()? It seems to be not much better than its %-
>> formatting
>> equivalent.
>
> Actually, formatting needs to become a function. The overloading of the
> arithmetic mod operator has proven to be unfortunate (if only because of
> precedence issue
Brett Cannon wrote:
> On 9/8/05, Tony Meyer <[EMAIL PROTECTED]> wrote:
>> [finding Tools/i18n/pygettext.py]
>> > You're right, I think Tools is probably a bad place for
>> > anything. If it's not part of the stdlib, I'll likely never
>> > find it.
>>
>> Agreed. Maybe with the introduction of -m
Martin v. Löwis wrote:
> Neal Norwitz wrote:
>> This code doesn't really work in general. It assumes that any append
>> function call is a list method, which is obviously invalid. But if a
>> variable is known to be a list (ie, local and assigned as list
>> (BUILD_LIST) or a list comprehension),
Hi,
looking at bug #1283289, I saw that the term "keyword parameter" is used in
Python/getargs.c, mixed with "keyword argument".
Grepping through the source, "keyword parameter" had 43 matches, while
"keyword argument" had 430. Should the "parameter" form be extinguished?
Reinhold
(And BTW, sho
e is argument for the call site but parameter for the
> function/method definition. So you can't just count occurrences.
>
> On 9/14/05, Reinhold Birkenfeld <[EMAIL PROTECTED]> wrote:
>> Hi,
>>
>> looking at bug #1283289, I saw that the term "keyword parame
Hi,
some time ago, I proposed a string method "dedent" (which currently is in the
textwrap module). The RFE is at http://python.org/sf/1237680.
Any opinions? If I don't get positive comments, I'll reject it.
Reinhold
--
Mail address is perfectly valid!
nality of "dedenting" a block that it's better to keep it as
> Python source code.
>
> On 9/14/05, Reinhold Birkenfeld <[EMAIL PROTECTED]> wrote:
>> Hi,
>>
>> some time ago, I proposed a string method "dedent" (which currently is in t
[EMAIL PROTECTED] wrote:
> Update of /cvsroot/python/python/dist/src/Lib
> In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv31892
>
> Modified Files:
> Tag: release24-maint
> urllib.py
> Log Message:
> Sync-up with patches to the head.
> Includes SF 1016880: urllib.urlretrieve si
Raymond Hettinger wrote:
> [Reinhold Birkenfeld]
>> This last patch includes a new exception, are you sure that this can
> be
>> safely backported?
>
> Not too worried about it. Better to have the exception reported than
> the silent failure that confused the heck o
Neal Norwitz wrote:
> I ran 2.4.x through valgrind and found two small problems on Linux
> that have been fixed. There may be some other issues which could
> benefit from more eyes (small, probably one time memory leaks). The
> entire run is here:
>
> http://python.org/valgrind-2.4.2.out
>
> (I
Raymond Hettinger wrote:
> I propose that in Py3.0, the "and" and "or" operators be simplified to
> always return a Boolean value instead of returning the last evaluated
> argument.
No, please not. It's useful sometimes and doesn't hurt most times.
> 1) The construct can be error-prone. When an
Guido van Rossum wrote:
> Given this realization, I'm now -1 on Raymond's idea, and +1 on adding
> a conditional expression. I believe (y if x else z) was my favorite
> last time, wasn't it? I've changed the subject accordingly.
As the PEP states, I'm not sure if changing the customary order of "
Jason Orendorff wrote:
> Honestly, I think I would prefer this syntax. Examples from real
> code, before and after:
>
> lines = [line for line in pr.block.body
> if line.logical_line.strip() != '']
> lines = [for line in pr.block.body:
> if line.logical_line
Anthony Baxter wrote:
> Starting in about 11 hours time, the release24-maint branch is FROZEN
> for the 2.4.2c1 release. The freeze will last for around a day, and
> then we're in a state of mostly-frozen for another week, until 2.4.2
> (final). During that week, please don't check things into t
Sokolov Yura wrote:
> Sorry for looking in every hole.
> Just a suggestion.
>
> A= condition and first or second
> problem is in case when first in (None,0,[],"").
> May be invent new operator 'take'.
> take - returns right operator when left evals to True and stops
> computing condidtional expr
Hi,
a general question. Consider:
class A(list):
def __setitem__(self, index, item):
# do something with index and item
return list.__setitem__(self, index, item)
lst = A([1,set()])
lst[0] |= 1
lst[1] |= set([1])
Do we want lst.__setitem__ to be called in the second inplac
Phillip J. Eby wrote:
>>A case where this matters is here: http://python.org/sf/1306777
>
> I've closed it as invalid; the behavior is as-defined.
>
> In principle, there *could* be an optimization to avoid rebinding the
> lvalue in the case where the __i*__ form did return self. But using it
Hi,
I looked whether I could make the test suite pass again
when compiled with --disable-unicode.
One problem is that no Unicode escapes can be used since compiling
the file raises ValueErrors for them. Such strings would have to
be produced using unichr().
Is this the right way? Or is disabling
Martin v. Löwis wrote:
> Reinhold Birkenfeld wrote:
>> One problem is that no Unicode escapes can be used since compiling
>> the file raises ValueErrors for them. Such strings would have to
>> be produced using unichr().
>
> You mean, in Unicode literals? There are va
Greg Ewing wrote:
> Guido van Rossum wrote:
>
>> BTW, what should
>>
>> [a, b, *rest] = (1, 2, 3, 4, 5)
>>
>> do? Should it set rest to (3, 4, 5) or to [3, 4, 5]?
>
> Whatever type is chosen, it should be the same type, always.
> The rhs could be any iterable, not just a tuple or a list.
>
Sokolov Yura wrote:
> May be allow modules to define __getattr__ ?
>
> def __getattr__(thing):
> try:
> return __some_standart_way__(thing)
> except AttributeError:
> if thing=="Queue":
>import sys
>from Queue import Queue
>
Martin Blais wrote:
> On 10/3/05, Michael Hudson <[EMAIL PROTECTED]> wrote:
>> Martin Blais <[EMAIL PROTECTED]> writes:
>>
>> > How hard would that be to implement?
>>
>> import sys
>> reload(sys)
>> sys.setdefaultencoding('undefined')
>
> Hmmm any particular reason for the call to reload() here?
Michele Simionato wrote:
> As other explained, the syntax would not work for functions (and it is
> not intended to).
> A possible use case I had in mind is to define inlined modules to be
> used as bunches
> of attributes. For instance, I could define a module as
>
> module m():
> a = 1
>
Raymond Hettinger wrote:
> [Martin Blais]
>> > I'm always--literally every time-- looking for a more functional
> form,
>> > something that would be like this:
>> >
>> ># apply dirname() 3 times on its results, initializing with p
>> >... = repapply(dirname, 3, p)
>
> [Greg Ewing]
>> Maybe
Hi,
on my machine, "make test" hangs at test_colorsys.
Careful investigation shows that when the bytecode is freshly generated
by "make all" (precisely in test___all__) the .pyc file is different from what a
direct call to "regrtest.py test_colorsys" produces.
Curiously, a call to "regrtest.py t
Hi,
don't know if this is known here, but it seems we have quite a long way to go:
http://kuerzer.de/python3
Reinhold
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.pytho
Guido van Rossum wrote:
> Has this been handled yet? If not, perhaps showing the good and bad
> bytecode here would help trigger someone's brain into understanding
> the problem.
I've created a tracker item at www.python.org/sf/1370322.
Reinhold
--
Mail address is perfectly valid!
Ian Bicking wrote:
> Guido van Rossum wrote:
>> On 12/14/05, Barry Warsaw <[EMAIL PROTECTED]> wrote:
>>
>>>On Thu, 2005-12-15 at 11:13 +1100, Dave Cole wrote:
>>>
>>>
The only thing I strongly disagree with is the promotion of javaNaming
to equal footing with python_naming.
>>>
>>>Actually
1 - 100 of 110 matches
Mail list logo
