Re: [Python-Dev] Ruby-style Blocks in Python [Pseudo-PEP]
On 8 Mar 2009, at 15:13, tav wrote: Apologies for bringing up an old issue, but I think I've worked out a Pythonic syntax for doing Ruby-style blocks. The short of it is: with employees.select do (emp): if emp.salary > developer.salary: return fireEmployee(emp) else: return extendContract(emp) My train of thought when seeing this: 1. Ok, "with" it's a context manager. 2. Huh, no it's not, "do", it's a loop. 3. What on earth is emp? Where's that defined? Why the parens? 4. Where do those returns return to? 5. I have no idea what this does. Ah, now, reading your Python alternative, defining a function then passing it is, it's more clear. This is completely incomprehensible to me, it doesn't feel like python. I'd rather define the throwaway function, anonymous callables that do complex things aren't my kind of thing. Give them a sensible name, put them in a utils module, and import it where needed, it's much clearer. Matt ___ 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] syntax warnings don't go through warnings.warn?
On 1 Jun 2009, at 17:50, Dino Viehland wrote: I’m just a little surprised by this - Is there a reason why syntax warnings are special and untrappable via warnings.warn? Why should this work? From the docs... "Python programmers issue warnings by calling the warn() function defined in this module. (C programmers use PyErr_WarnEx; see Exception Handling for details)." Check out the warnings.catch_warnings context manager, but if you have any further questions please direct them to the normal Python mailing list, this is for development _of_ Python only. Matthew ___ 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] syntax warnings don't go through warnings.warn?
On 1 Jun 2009, at 18:42, Michael Foord wrote: Dino is developing Python - he's one of the core developers of IronPython Ah, sorry, I'm bad with names, don't always pick up on who is who! and I suspect he is asking whether this is intentional, and IronPython should implement the same behaviour, or whether it is a bug. The docs do seem to be clear though, warnings.warn creates a warning, but there are multiple other ways to do it, it's a convenience method. Matt ___ 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] FINAL PROPULSION OPEN SOURCE ENGINE VARIANT FOR THE F-35 JOINT STRIKE FIGHTER
On 13 Jun 2009, at 00:01, OMEGA RED wrote: DEVELOP THE FIRST AND ONLY COMPLETELY OPEN SOURCE VARIANT OF THE PROPULSION ENGINE FOR THE F-35 JOINT STRIKE FIGHTER You're unlikely to find many people who want to help use open-source to facilitate murder. HOW MANY OUT THERE WANT TO HELP IN THIS ENDEAVOR ? Nobody here. You're off topic, this list is for development of Python, not pet projects. Matt ___ 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] FINAL PROPULSION OPEN SOURCE ENGINE VARIANT FOR THE F-35 JOINT STRIKE FIGHTER
On 13 Jun 2009, at 01:00, Guido van Rossum wrote: That's a rather presumptuous statement. Despite the poster's use of SHOUTING I don't see a reason to tell them they should use proprietary software just because you disagree with their politics Oh, I didn't mean they should use proprietary software, just that in my experience the kind of people who are active in open source are quite anti-war, green, etc. There are notable exceptions, but I know people who worry that their work will have military applications, and who turn down projects because of it. You're more likely to get people who are interested in aviation with some programming background (universities do teach coding to engineers, afterall), than the other way around. Matt ___ 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] surprised to "++" and "--"
I know that there is no "++" or "--" operator in python, but if "var++" or something like that in my code(you know, most of C/C++ coders may like this),there is nothing wrong reported and program goes on just like expected!! This is obscure, maybe a bug. Hi, Firstly, this list is for the development of Python, not with Python, questions about problems you're having should generally go to the users' list. Bug reports should go to the bug tracker at http://bugs.python.org/ However, in this particular case, there's no point submitting it; you have made a mistake somewhere. As you say, there is no ++ or -- unary postfix operator, but this DOES raise a SyntaxError: >>> var = 1 >>> var++ File "", line 1 var++ ^ SyntaxError: invalid syntax The prefix form is valid, as + and - are both valid prefix unary operators: >>> ++var 1 >>> --var 1 Which are equivalent to: >>> +(+1) 1 >>> -(-1) 1 If you were to try this with something that didn't implement __neg__ and __pos__, such as strings, you'd get: >>> ++var Traceback (most recent call last): File "", line 1, in ? TypeError: bad operand type for unary + Hope this clarifies things for you, Matthew ___ 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] standard libraries don't behave like standard 'libraries'
On 2009-11-12, at 1136, Sriram Srinivasan wrote: standard libraries i meant the standard libraries used. and what i asked for is for(in python) both the standard-libraries and the standard libraries used. c the term (intra and inter library management) which includes the default standard libraries and other standard libraries I don't think you're using the correct terminology. The standard library is what is shipped with the interpreter. It's the only thing that's common between all users of that interpreter, i.e. it's standard. what if there is another site where only eggs of python.org containing add-on standard libraries are distributed and noone is allowed to upload stuff except the python.org or PSF. The PSF does not maintain add-on libraries, nor can it make guarantees about other add-ons libraries. So, you want to make libs that are currently part of the standard library external libs available via PyPI? Not exactly via PyPI but something similar to it. Again, why? and don't compare C++ with python. both have their own + & - Frankly, comparing and contrasting with other languages is very useful, I have little to no idea what you're talking about, and doubt it's got anything to do with the development of the Python language. Matthew ___ 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] standard libraries don't behave like standard 'libraries'
Oh, I see.
use library 1.1.5
versus
use library 1.1.6 #thats all now i get all features
That's part of pkg_resources. It looks like this:
pkg_resources.require("mylibrary==1.1.6")
import mylibrary
There are plenty of other ways to manage this, most people use systems
like virtualenv or buildout, but that's a discussion for the normal
python mailing list, not the development one.
Hope that helps,
Matt
___
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] Contribute
On 2010-03-30, at 0006, Valerio Turturici wrote: Have you any advice for me? :) Also, have a look at Google's Summer of Code programme. It is a good way to get involved with a large project. Matthw ___ 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 3.0.1
On 27 Jan 2009, at 23:56, Barry Warsaw wrote:
Also, 3.0 is a special case because it is IMO a broken release.
AFAICT, it is not in any distro yet. Hopefully, no one will keep
it around
and it will vanish silently.
I stand by my opinion about the right way to do this. I also think
that a 3.1 release 6 months after 3.0 is perfectly fine and serves
our users just as well.
I'm lurking here, as I usually have nothing to contribute, but here's
my take on this:
I'm generally a Python 2.4 user, but have recently been able to tinker
in 2.6. I hope to be using 2.6 as my main language within a year. I
anticipate dropping all 2.4 projects within 5 years. We have not yet
dropped 2.3.
I didn't know 3.0 is considered a broken release, but teething
troubles are to be expected. Knowing this, I would be reluctant to
use 3.0.1, it sounds like too small a change. If you put a lot of
things into a minor point release you risk setting expectations about
future ones. From the 2.x series I 2.x.{y,y+1) to be seemless, but 2.
{x,x+1} to be more performant, include new features and potentially
break comlpex code.
I personally would see a 3.1 with C based IO support as being more
sensible than a 3.0.1 with lots of changes. I wouldn't worry about
3.x being seen as a dead duck, as you say it's not in wide use yet.
We trust you guys, if there's been big fixes there should be a big
version update. Broadcast what's been made better and it'll encourage
us to try it.
Matt
___
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] pprint(iterator)
On 29 Jan 2009, at 21:54, Nick Coghlan wrote:
For the "reiterable" cases like dictionary views (where the object is
not consumed), an appropriate __str__ or __repr__ should be written).
Indeed, instead of having a __pprint__ why not just allow a __repr__
to reformat its output?
dict having:
def __repr__(self, pretty=False):
if pretty:
return "{\n a: 1\n b: 2\n}"
else:
return "{a: 1, b: 2}"
That way you can specify your own pretty format, intending it to still
be a valid __repr__ and pprint can do:
try:
print(obj.__repr__(pretty=True))
except TypeError:
print(prettify(repr(obj)))
That way it's opt in, doesn't have a special method, and includes the
mental prompt "this should eval() to obj"
Matt
___
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
